This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH] remote_detach() and inferior_pid
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Subject: Re: [PATCH] remote_detach() and inferior_pid
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Thu, 17 Feb 2000 17:53:40 -0500
- CC: Andrew Cagney <ac131313 at cygnus dot com>, Jim Kingdon <kingdon at redhat dot com>, gdb-patches at sourceware dot cygnus dot com
- Organization: Red Hat , Inc. - Toronto
- References: <14505.29243.656290.516276@kwikemart.cygnus.com> <bd7pynspv.fsf@rtl.cygnus.com> <38ABADEC.F0320CCB@cygnus.com> <14508.25526.45779.825197@kwikemart.cygnus.com> <38AC660E.7D898F58@cygnus.com> <14508.26505.557237.402681@kwikemart.cygnus.com>
Elena Zannoni wrote:
>
> Fernando Nasser writes:
> > Elena Zannoni wrote:
> > >
> > > OK, all in agreement then. I'll add a generic_mourn_inferior() call in
> > > there. New patch follows. OK to check in?
> > >
> >
> > Hum, shouldn't we just change the calls to pop_target() by calls to
> > remote_mourn() and remote_asynch_mourn() instead?
> >
>
> True, I thought about that, but remote_mourn / remote_async_mourn call
> unpush_target(), instead of pop_target(). I am not sure if that's an
> important difference, or just a coincidence.
>
If your target does not have a to_close (it is inherited), then you need
to call pop_target() because it calls the to_close of current_target
(which will have one, even if the default).
The other difference is that pop_target() makes gdb dump core if it does
not find the target in the stack, which will never happen as it passes
the top of the stack as a parameter.
I believe for all practical purposes of remote.c they are equivalent. I
even prefer the unpush one.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@cygnus.com
2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311
Toronto, Ontario M4P 2C9 Fax: 416-482-6299