Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Daniel Jacobowitz <drow@false.org>,
	 Vladimir Prus <vladimir@codesourcery.com>,
	 Marc Khouzam <marc.khouzam@ericsson.com>,
	 gdb-patches@sources.redhat.com,
	 Nick Roberts <nickrob@snap.net.nz>
Subject: Re: MI solib notification
Date: Thu, 12 Feb 2009 19:45:00 -0000	[thread overview]
Message-ID: <200902121806.45822.pedro@codesourcery.com> (raw)
Message-ID: <20090212194500.MhR4-nx00JjpCevH5rQeiq_JSLE16Dcji-BJFTPdPqM@z> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2009-02-12 18:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-30 23:44 Vladimir Prus
     [not found] ` <utz7gzcmo.fsf@gnu.org>
2009-02-01 17:53   ` Daniel Jacobowitz
2009-02-01 18:22     ` Eli Zaretskii
2009-02-01 18:29       ` Daniel Jacobowitz
2009-02-17 19:09         ` Vladimir Prus
2009-02-17 19:45           ` Eli Zaretskii
2009-02-17 19:49             ` Vladimir Prus
2009-02-17 20:30               ` Eli Zaretskii
2009-02-17 21:45                 ` Vladimir Prus
2009-02-17 21:59                   ` Vladimir Prus
2009-02-18  7:31                     ` Eli Zaretskii
2009-02-18 10:19                       ` Vladimir Prus
2009-02-18 19:53                         ` Eli Zaretskii
2009-02-18 20:04                           ` Vladimir Prus
2009-02-18 22:28                             ` Eli Zaretskii
2009-02-18  4:24                   ` Eli Zaretskii
2009-02-17 21:37               ` Daniel Jacobowitz
2009-02-17 22:10               ` Pedro Alves
2009-02-18  2:01                 ` Pedro Alves
2009-02-01 18:04 ` Daniel Jacobowitz
2009-02-12  9:12   ` Vladimir Prus
2009-02-12 13:22     ` Daniel Jacobowitz
2009-02-12 15:02       ` Vladimir Prus
2009-02-12 15:13         ` Daniel Jacobowitz
2009-02-12 17:35           ` Tom Tromey
2009-02-12 18:02             ` Daniel Jacobowitz
2009-02-12 20:11               ` Tom Tromey
2009-02-12 20:17                 ` Vladimir Prus
2009-02-12 20:26                   ` Daniel Jacobowitz
2009-02-17 19:08                     ` Vladimir Prus
2009-02-12 18:06           ` Pedro Alves [this message]
2009-02-12 19:45             ` Pedro Alves
2009-02-12 19:56             ` Tom Tromey
2009-02-12 19:58               ` Daniel Jacobowitz
2009-02-13  2:22               ` Joel Brobecker
2009-02-01 18:47 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200902121806.45822.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=marc.khouzam@ericsson.com \
    --cc=nickrob@snap.net.nz \
    --cc=vladimir@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox