From: Daniel Jacobowitz <drow@mvista.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Kimball Thurston <kimball@sgrail.com>,
Andrew Cagney <ac131313@cygnus.com>,
gdb@sources.redhat.com
Subject: Re: gdb and dlopen
Date: Thu, 08 Nov 2001 00:22:00 -0000 [thread overview]
Message-ID: <20011118144510.A19538@nevyn.them.org> (raw)
In-Reply-To: <1011017195838.ZM5524@ocotillo.lan>
On Wed, Oct 17, 2001 at 12:58:38PM -0700, Kevin Buettner wrote:
> On Oct 17, 12:09pm, Kimball Thurston wrote:
>
> > Along the same lines of just trying to clean up unnecessary work, I
> > was seeing 2 scans of all the open dsos for each dlopen call - it
> > looks like we are getting 2 BPSTAT_WHAT_CHECK_SHLIBS events (in
> > infrun.c) for each dlopen which causes us to rescan everything. Is
> > there a way to distinguish these two events, and only do the scan
> > once?
>
> I haven't looked at how hard it'd be, but it seems to me that it'd
> be a good idea for gdb to note that a shlib event has happened without
> immediately doing anything about it. Then, when the target stops
> for some other reason (than a shlib event), we handle all of them at
> once. This should cut down on the memory traffic greatly.
Actually implementing this, at first glance, is easy. However, there's
a couple of interesting issues. For instance, suppose that we want to
reset a breakpoint in a shared library; we need to read in the symbols
for that shared library before we can do that. If we defer it, and
there are no other breakpoints, then we'll never set the breakpoint and
never stop.
Thoughts?
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2001-11-18 19:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <y3radyrjqf8.wl@paladin.sgrail.com>
2001-10-16 13:15 ` Daniel Jacobowitz
2001-10-16 18:23 ` Kimball Thurston
[not found] ` <20011016213252.A8694@nevyn.them.org>
2001-10-16 19:03 ` Daniel Jacobowitz
2001-10-16 20:04 ` Kimball Thurston
2001-10-16 20:17 ` Andrew Cagney
2001-10-16 22:08 ` Daniel Jacobowitz
2001-10-16 22:19 ` Daniel Jacobowitz
[not found] ` <y3rzo6qx1ej.wl@paladin.sgrail.com>
2001-10-16 22:52 ` Kimball Thurston
2001-10-17 8:07 ` Mark Kettenis
2001-10-17 8:29 ` H . J . Lu
2001-10-17 11:09 ` Daniel Jacobowitz
2001-10-17 14:26 ` Mark Kettenis
2001-10-17 14:34 ` Daniel Jacobowitz
2001-10-17 8:54 ` Andrew Cagney
2001-10-17 15:08 ` Kevin Buettner
2001-10-17 15:57 ` Andrew Cagney
2001-10-17 17:05 ` Daniel Jacobowitz
2001-10-17 23:14 ` Andrew Cagney
2001-10-17 8:42 ` Andrew Cagney
2001-10-17 11:15 ` Daniel Jacobowitz
2001-10-17 12:09 ` Kimball Thurston
2001-10-17 12:58 ` Kevin Buettner
2001-11-08 0:22 ` Daniel Jacobowitz [this message]
2001-11-08 8:17 ` Kevin Buettner
2001-11-08 9:44 ` Daniel Jacobowitz
2001-11-08 10:49 ` Kevin Buettner
2001-11-08 11:14 ` Daniel Jacobowitz
2001-11-08 16:17 ` Andrew Cagney
2001-10-16 22:25 ` Kimball Thurston
2001-10-16 15:05 ` H . J . Lu
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=20011118144510.A19538@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=kevinb@cygnus.com \
--cc=kimball@sgrail.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