This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MI solib notification
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Daniel Jacobowitz <drow at false dot org>, Vladimir Prus <vladimir at codesourcery dot com>, Marc Khouzam <marc dot khouzam at ericsson dot com>, gdb-patches at sources dot redhat dot com, Nick Roberts <nickrob at snap dot net dot nz>
- Date: Thu, 12 Feb 2009 18:06:45 +0000
- Subject: Re: MI solib notification
- References: <200901310010.46738.vladimir@codesourcery.com> <200902121801.55254.vladimir@codesourcery.com> <20090212151337.GA9460@caradoc.them.org>
On Thursday 12 February 2009 15:13:37, Daniel Jacobowitz wrote:
> On Thu, Feb 12, 2009 at 06:01:54PM +0300, Vladimir Prus wrote:
> > Yes, this runs everywhere except a.out and marks all breakpoints in solibs
> > disabled, without printing any messages. *Then* we look over all solibs
> > and call observer, but since all breakpoints are already disabled,
> > breakpoint.c:disable_breakpoints_in_unloaded_shlib won't do anything,
> > and won't say anything either.
>
> I see. ?The comment in clear_solibs means that we will break SunOS
> a.out shared libraries if we do this; they were previously not
> disabled, since they won't ever be re-enabled. ?So I suggest not
> making the observer call on a.out either. ?Otherwise OK.
Sorry to pitch in this late, but, doesn't it sound wrong when
we end up conditionally calling observers for the benefit of
some specific observer? When we do that, we're likelly to end
up adding some new observer in the future, for a different
purpose, and realise that it isn't getting called in some
situation.
I'd prefer in these cases to see us move in the direction where
the observer itself has the needed information to decide if it
should skip its whatever-action, or, to add a new
notification.
It seems there's a bit of overloading going on here:
- MI wants to know whenever GDB removes a shared library from
it's lists. Be that when the inferior unloads the shared library,
or after the inferior having exited. Because we currently
leave the shared list intact after the inferior having exited, and
only clear it on the subsequent re-run, this even means that
MI will get an =thread-group-exited notification when the inferior
exits, and only when the inferior is re-run, will MI output this
new =library-unloaded notification. So, this shows that "unloaded"
means unloaded from gdb, not unloaded from the inferior, unless that
is fixed to be made consistent. E.g., core files when they're closed
do clear the solist.
- The breakpoints.c:disable_breakpoints_in_unloaded_shlib observer
currently is notified whenever the inferior unloads an solib, but
not when we clear the list to start over. If we want it to get
the notification also in that case, can't we push the a.out checks
down there instead? If needed, we could add a parameter to the
notification, or come up with a new notification.
--
Pedro Alves