From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-27276-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 30740 invoked by alias); 2 Jan 2007 21:39:26 -0000
Received: (qmail 30732 invoked by uid 22791); 2 Jan 2007 21:39:26 -0000
X-Spam-Check-By: sourceware.org
Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Jan 2007 21:39:18 +0000
Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) 	by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id l02Laeqg025425; 	Tue, 2 Jan 2007 22:36:40 +0100 (CET)
Received: (from kettenis@localhost) 	by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id l02Laeu4002267; 	Tue, 2 Jan 2007 22:36:40 +0100 (CET)
Date: Tue, 02 Jan 2007 21:39:00 -0000
Message-Id: <200701022136.l02Laeu4002267@brahms.sibelius.xs4all.nl>
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: jimb@codesourcery.com
CC: gdb@sourceware.org
In-reply-to: <m3ps9xcir0.fsf@codesourcery.com> (message from Jim Blandy on 	Tue, 02 Jan 2007 11:48:35 -0800)
Subject: Re: gdb very slow during 'step into'
References: <adeacfc10701020723g245481a7r7848b00db337ac00@mail.gmail.com> 	<m3zm91kz07.fsf@codesourcery.com> 	<20070102193049.GA19762@nevyn.them.org> <m3ps9xcir0.fsf@codesourcery.com>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-01/txt/msg00024.txt.bz2

> 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