This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] detach properly from process
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Sat, 16 Aug 2003 15:22:57 -0400
- Subject: Re: [RFC] detach properly from process
- References: <16178.43537.608996.268901@localhost.redhat.com>
On Thu, Aug 07, 2003 at 03:35:45PM -0400, Elena Zannoni wrote:
>
>
> 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.
I think detach shouldn't close the BFD. The above is really the
bizarre case - if you've specified a file explicitly, then we should
hold on to it! User knows what they're doing.
There we've guessed the file implicitly, though. In that case it might
make sense to close it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer