Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: jimb@codesourcery.com
Cc: gdb@sourceware.org
Subject: Re: gdb very slow during 'step into'
Date: Tue, 02 Jan 2007 21:39:00 -0000	[thread overview]
Message-ID: <200701022136.l02Laeu4002267@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <m3ps9xcir0.fsf@codesourcery.com> (message from Jim Blandy on 	Tue, 02 Jan 2007 11:48:35 -0800)

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 02 Jan 2007 11:48:35 -0800
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > On Tue, Jan 02, 2007 at 11:30:16AM -0800, Jim Blandy wrote:
> >> If you set the environment variable LD_BIND_NOW to a non-empty value
> >> before running your program (use GDB's 'set env' command), does that
> >> eliminate the slow steps?
> >
> > Is this where we step through the dynamic linker?  We really should
> > avoid that...
> 
> I'm pretty sure we set a breakpoint at the function's true entry point
> (since we know it too), and wait for that to hit.  I believe I made
> that change myself years ago.  But maybe something broke.

Quite likely.  The code in glibc-tdep.c does rely on some knowledge
about the internals of the implementation.  The glibc developers have
been quite aggressive about not experting symbols in the recent past.
Do it might very well be that the lookup for "_dl_runtime_resolve" or
"fixup" fails, especially on a system whithout debug info for glibc.

Mark


  reply	other threads:[~2007-01-02 21:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-02 15:24 dodji Seketeli
2007-01-02 19:29 ` Jim Blandy
2007-01-02 19:31   ` Daniel Jacobowitz
2007-01-02 19:48     ` Jim Blandy
2007-01-02 21:39       ` Mark Kettenis [this message]
2007-01-02 22:59         ` Andreas Schwab
2007-01-02 23:45           ` Jim Blandy
2007-01-02 23:57             ` Daniel Jacobowitz
2007-01-03 15:03               ` Andreas Schwab
2007-01-03  9:14   ` dodji Seketeli
2007-01-03 19:52     ` Jim Blandy
2007-01-03 19:59       ` Smith, Stephen (SWCOE)
2007-01-03 21:19         ` Jim Blandy
2007-01-03 20:59       ` Andreas Schwab
2007-01-03 21:17         ` Jim Blandy
2007-01-03 21:58       ` dodji Seketeli
2007-01-03 23:37         ` Jim Blandy
2007-01-03 23:42           ` Daniel Jacobowitz
2007-01-04  0:00             ` Jim Blandy
2007-01-04 10:04           ` dodji Seketeli
2007-01-04  3:28         ` Daniel Jacobowitz
2007-01-04 10:10           ` dodji Seketeli
2007-01-04 13:53             ` 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=200701022136.l02Laeu4002267@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb@sourceware.org \
    --cc=jimb@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