This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix remote.c incorrectly using pop_target (wrt btrace)
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org, "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Date: Fri, 22 Mar 2013 16:58:01 +0000
- Subject: Re: [patch] Fix remote.c incorrectly using pop_target (wrt btrace)
- References: <20130311172836 dot GA22575 at host2 dot jankratochvil dot net> <513EFD81 dot 6050401 at codesourcery dot com> <20130315195451 dot GB19841 at host2 dot jankratochvil dot net>
On 03/15/2013 07:54 PM, Jan Kratochvil wrote:
> gdb/
> 2013-03-15 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> * remote.c (remote_unpush_target): New function.
> (remote_open_1): Remove two pop_target calls, update one comment, add
> comment to target_preopen call. Replace pop_target call by
> remote_unpush_target call.
> (interrupt_query, readchar, getpkt_or_notif_sane_1): Replace
> pop_target calls by remote_unpush_target calls.
>
Thanks. I think this is fine.
I notice that some targets, like spu-multiarch.c or dec-thread.c
don't seem to be very prepared to be brute-force deactivated. E.g.,
those targets (and linux-thread-db.c and bsd-uthread.c too), probably
more) are deactivated when symbols or shared libraries are unloaded,
and their to_close methods don't take care of cleaning up the target's
variables / local state. A similar scenario that doesn't
involve remote, is when going from 'threaded core debugging'
-> 'non-threaded core debugging'. But since target_pre_inferior
discards the DSOs of the current inferior, and these targets are
generally not multi-inferior aware, I guess things end up alright.
This is very much a preexisting wart. I suspect we'll end up
getting back to this at some not-so-distant point. :-)
--
Pedro Alves