This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb very slow during 'step into'
"dodji Seketeli" <dodji@seketeli.org> writes:
>> 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?
>
> Wow, yes. It does eliminate the problem. Thank you !.
I'm glad that helped! But setting LD_BIND_NOW is just a workaround;
GDB ought to work properly without that. Could you apply the
following patch to GDB and see if it makes the problem go away, even
with LD_BIND_NOW left unset?
(Tested without regressions on Fedora Core 6 IA-32. I haven't been
able to reproduce the problem myself, so I'm just guessing that this
is the patch.)
gdb/ChangeLog:
2007-01-03 Jim Blandy <jimb@codesourcery.com>
* glibc-tdep.c (glibc_skip_solib_resolver): Look for '_dl_fixup',
then plain 'fixup'.
Index: gdb/glibc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/glibc-tdep.c,v
retrieving revision 1.3
diff -u -r1.3 glibc-tdep.c
--- gdb/glibc-tdep.c 17 Dec 2005 22:34:00 -0000 1.3
+++ gdb/glibc-tdep.c 3 Jan 2007 19:49:17 -0000
@@ -90,8 +90,14 @@
if (resolver)
{
+ /* This is the name used in the dynamic linker at the beginning
+ of 2007. */
struct minimal_symbol *fixup
- = lookup_minimal_symbol ("fixup", NULL, objfile);
+ = lookup_minimal_symbol ("_dl_fixup", NULL, objfile);
+
+ /* This is the name used in older versions. */
+ if (! fixup)
+ fixup = lookup_minimal_symbol ("fixup", NULL, objfile);
if (fixup && SYMBOL_VALUE_ADDRESS (fixup) == pc)
return frame_pc_unwind (get_current_frame ());