I'm having trouble with a couple of things in GDB: - if I make a breakpoint pending on future shared library load, the breakpoint will not be hit when the code is executed after the library has been loaded. - the symbols from shared objects loaded with dlopen() are not automatically loaded, I have to use the command "sharedlibrary" once the shared object has been loaded to load in the symbols I think both of these are related to the following warning that I get when running my program in GDB: warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Some searching on the net led me to this bug report: http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=236&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26cmd%3Dsubmit%2520query%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3Ddynamic%2520linker%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26sortby%3DResponsible%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed%26.cgifields%3Doriginatedbyme%26.cgifields%3Dcolumns Unfortunately that one was last modified Fri Dec 06 14:55:09 PST 2002. I'm not certain the message describes the source of my problems, but I sure would like to know what it means and why I get it. Package versions: * sys-devel/binutils Latest version installed: 2.14.90.0.8-r1 * sys-devel/gdb Latest version installed: 6.1 Emerge info: Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.6) ================================================================= System uname: 2.6.6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.4.14 distcc 2.14 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.kfk4ever.com/gentoo http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.gentoo.skynet.be/pub/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://ftp.easynet.nl/mirror/gentoo/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_overlay" SYNC="rsync://griffon26.kfk4ever.com/gentoo-portage" USE="X Xaw3d alsa apache2 avi bonobo cdr crypt cscope dedicated dga dvd encode ethereal fastcgi fbcon freetds gd gdbm ggi gif gpm gstreamer gtk gtk2 imlib ipv6 jikes joystick jpeg libwww lirc mad mcal memlimit mikmod mmx motif mozilla mpeg mpi mysql ncurses nls nocd oggvorbis opengl pam pdflib perl plotutils png pnp python qt quicktime readline samba sdl slang snmp spell sse ssl svga tcltk tcpd tiff truetype trusted usb wmf wxwindows x86 xml xml2 xmms xosd xv zlib"
Are you sure that you can't handle that problem with proper settings? Is the same warning produced by previous gdb? Reassigning to the toolchain group since I'm not sure I have enough time to pay full attention to it
I just tried 5.3 and 6.0-r1 and I got the same warning. Also, symbols weren't loaded automatically for shared objects loaded with dlopen(); I had to use "sharedlibrary". Breakpoints pending on shared library load seem to be a feature of 6.1. I'd be happy to do some more testing if you can tell me what to try. I'm not sure what you mean with "proper settings". I think I have things set up correctly.
I wasn't having any problems with gdb 2 days ago, but yesterday I updated to glibc-2.3.3.20040420 (and gcc-3.3.3-r6). Now I'm getting the warning message noted here right after running the program, and then it breaks a couple of lines later than it should in the function I set the breakpoint on. Using gdb on python (which was built with the old gcc) results in the same message, as does using even an "empty" program. Due to the nature of the warning, I would have to assume this is somehow directly related to the glibc update, and I can see the reporter is running (essentially) the same one as well. I'd love to downgrade and test, but I was hesitant enough to even upgrade -- apparently with good reason -- and am even more so to go the other way. HTH anyway.
Make sure you compile glibc with "FEATURE=nostrip" enabled. You set FEATURE in the make.conf. It seems to me that when ld-2.3.3.so is stripped GDB is b0rked... tux ~$ file /lib/ld-2.3.3.so /lib/ld-2.3.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped It should read not stripped as it does in my case. The the error msg goes away.
I tried it out and you're right, if ld-*.so is not stripped, everything works fine. But that is only a work-around. gdb is supposed to use the dynamic symbol _r_debug, which has a member r_brk that points to a _dl_debug_state function where the debugger can set its breakpoint. > file /lib/ld-2.3.4.so /lib/ld-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped > nm -D /lib/ld-2.3.4.so 000187b4 B _r_debug As you can see, _r_debug is available. I don't know why it doesn't work. And debugging a debugger that is debugging an executable that is being dynamically linked to a dynamic library causing the debugger to look for a dynamic symbol in the dynamic linker sounds like a good way to get a headache.
this bug should be fixed in glibc 2.3.4.20040808, 2.3.4.20040619-r1, 2.3.2-r11, 2.3.2-r10, and 2.2.5-r9. re-open if the problem persists
I'm still seeing this problem in glibc-2.3.4.20040808-r1; emerging glibc with FEATURES="nostrip" cures it as before. Is this expected with this version? Below is emerge --info *after* the nostrip flag was added. Portage 2.0.51-r15 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.10 i686) ================================================================= System uname: 2.6.10 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 24 2005, 22:31:12)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.7.9-r1, 1.5, 1.9.4, 1.6.3, 1.4_p6, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nostrip sandbox sfperms" GENTOO_MIRRORS="ftp://mirrors.blueyonder.co.uk/mirrors/gentoo ftp://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.ipv6.uni-muenster.de/pub/linux/distributions/gentoo http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ http://ftp6.uni-erlangen.de/pub/mirrors/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X apm avi berkdb bitmap-fonts cdb cdparanoia cdr crypt cups curl dvd dvdr dvdread emacs emboss encode esd ethereal f77 fam flac font-server foomaticdb fortran ftp gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 imagemagick imap imlib ipv6 joystick jpeg kde libg++ libwww lm_sensors mad mbox mikmod mime mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nvidia ogg oggvorbis opengl oss pam pda pdflib perl php png posix postgres ppds python qt quicktime readline samba sdl sox spell ssl svga tcpd tetex threads tiff truetype truetype-fonts type1-fonts usb vcd videos wxwindows xine xml xml2 xmms xpm xv xvid zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
I can reproduce here too.. using sys-libs/glibc-2.3.4.20040808-r1, gcc 3.3.5-r1 and gdb 6.3 or 5.3 .. If I recompile the binary as static the bug disapears. The main bug is that when I try to run many simple programs inside gdb I get: Warning: Cannot insert breakpoint -2. Error accessing memory address 0x8b0: Input/output error. and then it stops.. not good.. I'll trying recompiling glibc with nostrip. Re-opening
can'T reproduce anymore
How'd you do that? Could you please give some version information (gcc, glibc, gdb)? I still get: (gdb) run Warning: Cannot insert breakpoint 1. Error accessing memory address 0x16cc8: Input/output error. ...on any simple program I try to debug!
that error sounds like a kernel issue make sure you're not using grsec or other security features
Sounds like a PIE issue actually, and you probably built gcc with USE=hardened. If that's the case, try using gcc-config to select the hardenednopie or vanilla gcc specfile. Alternatively, you can just build with gcc -fno-pie (though that'll break things if PIE is needed for some reason, I've seen it happen before, but only once with some nasty code that would segfault with the wrong CFLAGS anyway). If you're using PaX too and it enforces MPROTECT by default, install paxctl and do paxctl -m <binary>. If it wasn't built on your box, you may need to use chpax instead. And yes, the original issue here (with the dynamic linker breakpoint function stuff) disappeared long ago for me. Sorry I forgot to comment about it.
Thanks for your help! Compiling with compiler options "-fno-pie -nopie" finally enabled debugging with breakpoints on my system.
*** Bug 71072 has been marked as a duplicate of this bug. ***
