From: Joel Brobecker <brobecker@adacore.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: hacky fix for PR 12406
Date: Thu, 12 Jan 2012 05:59:00 -0000 [thread overview]
Message-ID: <20120112042946.GM31383@adacore.com> (raw)
In-Reply-To: <m34nw26pct.fsf@fleche.redhat.com>
> This patch changes the output to:
>
> (gdb) set stop-on-solib-events 1
> (gdb) r
> Starting program: /tmp/q
> [Inferior loaded library /lib64/ld-linux-x86-64.so.2]
> Stopped due to shared library event
>
> I could not find a good way to get the information about what library
> was loaded from the library-loading code to the bpstat_print code. This
> approach seems like a hack to me -- so I was wondering if anyone has a
> better suggestion.
Yeah, it doesn't look super great, but it is better than nothing, IMO.
It looks a lot easier to implement this on platforms that use
TARGET_WAITKIND_LOADED events, because we could associate the library
name to the target_waitstatus value. For other platforms where this
is based on a breakpoint rather than a kernel event, on the other
hand... I'm not even convinced that we'll get one breakpoint per
shared library being mapped. Particularly at startup time, I can
see us hitting one breakpoint once all SOs have been mapped, and
not before. If it were the case, attaching one shared-library event
per breakpoint event does not seem to make sense.
An idea that crossed my mind: Add a flag to each entry in our SO
list. Everytime we stop, we use that flag to determine which entries
are new. We can probably use something like the normal-stop hook to
set the flag just before giving the prompt back to the user. Would
that work? It would support the situation I mentioned above where
we get one breakpoint event for multiple shared libraries...
--
Joel
next prev parent reply other threads:[~2012-01-12 4:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 19:25 Tom Tromey
2012-01-12 0:12 ` Jan Kratochvil
2012-01-12 5:59 ` Joel Brobecker [this message]
2012-01-12 21:41 ` Tom Tromey
2012-01-13 15:48 ` Gary Benson
2012-01-12 11:40 ` Gary Benson
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=20120112042946.GM31383@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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