This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFC] detach properly from process
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Thu, 7 Aug 2003 15:35:45 -0400
- Subject: [RFC] detach properly from process
Say you have 2 processes running: the first process' executable is
called 'foo' with PID 12345, the second one is called 'bar' with PID 67890.
Then you do:
%gdb
(gdb) attach 12345
Attaching to process 12345
Reading symbols from /home/ezannoni/foo...done
(gdb) detach
Detaching from program: /home/ezannoni/foo, process 12345
(gdb) attach 67890
Attaching to program: /home/ezannoni/foo, process 67890
^^^^^^^^^^^^^^^^^^
Cannot access memory at address 0xfb8804
It didn't read the symbols from the new file 'bar' because the
exec_bfd was never reset to NULL. :-( exec_bfd is tested in the
get_exec_file() function which is called by child_attach(). If there
is an exec_bfd, reuse it.
I noticed that also kill would not clean the exec_bfd.
However, I am not sure what gdb's intended behavior is in these
circumstances. If you look at the testsuite, attach.exp, you will see
that after a 'detach' it does a 'file' (w/o args) to clean the old
symbols. So maybe it was OK to not get rid of the bfd, etc? I cannot
find anything in the docs about what detach is supposed to really do.
I always found the semantics of detach/kill etc to be quite
inconsistent.
elena
Index: inftarg.c
===================================================================
RCS file: /cvs/src/src/gdb/inftarg.c,v
retrieving revision 1.17
diff -u -p -r1.17 inftarg.c
--- inftarg.c 7 Feb 2003 04:21:34 -0000 1.17
+++ inftarg.c 7 Aug 2003 18:19:13 -0000
@@ -276,6 +276,7 @@ child_detach (char *args, int from_tty)
detach (siggnal);
inferior_ptid = null_ptid;
+ target_close (1);
unpush_target (&child_ops);
}
#else
@@ -490,6 +491,7 @@ child_has_exited (int pid, int wait_stat
static void
child_mourn_inferior (void)
{
+ target_close (1);
unpush_target (&child_ops);
generic_mourn_inferior ();
}