aboutsummaryrefslogtreecommitdiff
path: root/gdb/inf-child.h
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2021-05-13 15:28:42 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2021-05-13 15:29:00 -0400
commit737358ba1ed8b28820cc965f62027bb7417b132b (patch)
tree0f9448334b0cb9a06c42de6b561f30fc7224e5a0 /gdb/inf-child.h
parent294c36eb6ac9eaf761ec300fd400623ed5175203 (diff)
downloadgdb-737358ba1ed8b28820cc965f62027bb7417b132b.zip
gdb-737358ba1ed8b28820cc965f62027bb7417b132b.tar.gz
gdb-737358ba1ed8b28820cc965f62027bb7417b132b.tar.bz2
gdb: maybe unpush target from old inferior in inf_child_target::follow_exec
I realized that with "follow-exec-mode == new", the process target stayed pushed in the original inferior. This can cause a small incoherence: $ ./gdb -q -nx --data-directory=data-directory -ex "set follow-exec-mode new" --args execer args-for-execer Reading symbols from execer... (gdb) r Starting program: /home/smarchi/build/binutils-gdb/gdb/execer args-for-execer I am execer and my argv[1] is: args-for-execer process 3562426 is executing new program: /home/smarchi/build/binutils-gdb/gdb/execee [New inferior 2] [New process 3562426] I am execee and my argv[1] is: arg-for-execee [Inferior 2 (process 3562426) exited normally] (gdb) info inferiors Num Description Connection Executable 1 <null> 1 (native) /home/smarchi/build/binutils-gdb/gdb/execer * 2 <null> /home/smarchi/build/binutils-gdb/gdb/execee (gdb) maintenance print target-stack The current target stack is: - exec (Local exec file) - None (None) (gdb) inferior 1 [Switching to inferior 1 [<null>] (/home/smarchi/build/binutils-gdb/gdb/execer)] (gdb) maintenance print target-stack The current target stack is: - native (Native process) - exec (Local exec file) - None (None) On exec, when execution continues into inferior 2, the native target isn't unpushed from inferior 1. When inferior 2's execution finishes normally, inf_child_target::mourn_inferior unpushes the native target, because the native target has been implicitly opened. I think that if the native target was implicitly opened, it should be unpushed from inferior 1, just like it is unpushed from an inferior whose execution terminate. This patch implements that. gdb/ChangeLog: * inf-child.h (inf_child_target) <follow_exec>: New. * inf-child.c (inf_child_target::follow_exec): New. Change-Id: I782cc08d73d93a990f4e53611107f68b2cb58af1
Diffstat (limited to 'gdb/inf-child.h')
-rw-r--r--gdb/inf-child.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/gdb/inf-child.h b/gdb/inf-child.h
index d697a39..aa33c53 100644
--- a/gdb/inf-child.h
+++ b/gdb/inf-child.h
@@ -57,6 +57,9 @@ public:
void post_startup_inferior (ptid_t) override;
+ void follow_exec (inferior *follow_inf, ptid_t ptid,
+ const char *execd_pathname) override;
+
void mourn_inferior () override;
bool can_run () override;