[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gdb and dynamically loaded code

H.J. Lu writes:
> > Douglas Bates writes:
> > > I have version 4.16-2 of the gdb package installed.  When I start gdb
> > > I get the warnings
> > >  warning: Unable to find dynamic linker breakpoint function.
> > >  warning: GDB will be unable to debug shared library initializers
> > >  warning: and track explicitly loaded dynamic code.
> > > 
> > > It would be very helpful to me to be able to set breakpoints within
> > > dynamically loaded code.  Is there something I can change in the
> > > set-up for gdb to allow me to track explicitly loaded dynamic code?
> > 
> > Apparently, gdb can not handle a stripped ld-linux.so.1.  The symbols
> > gdb wants can be found in the .dynsym section so this could be
> > considered a bug in gdb but I'm not sure.  H.J., what do you think?
> How do you debug a stripped binary? Unless I am wrong, if you want 
> to debug ld-linux.so.1, you have to compile it with -g and don't strip
> it. It doesn't cost much in disk space.

H.J., I think you misunderstood.  We aren't debugging ld-linux.so.1.
We are debugging an ordinary binary.

When gdb starts a binary, it looks up the address of _dl_debug_state
so it can set a breakpoint in the dynamic linker to trap the loading
of shared libraries.  With a stripped ld-linux.so.1, gdb fails to find
the address of _dl_debug_state and issues the warning shown above.
However, _dl_debug_state is contained in the .dynsym section (which
doesn't get stripped) of ld-linux.so.1, so I'm thinking that it should
be possible for gdb to get the address from there even when
ld-linux.so.1 is stripped.

David Engel                        Optical Data Systems, Inc.
david@ods.com                      1001 E. Arapaho Road
(972) 234-6400                     Richardson, TX  75081

This message was delayed because the list mail delivery agent was down.

Reply to: