Summary: | GDB unable to find dynamic linker breakpoint function | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maurice van der Pot (RETIRED) <griffon26> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | axel.privat, bensberg, gentoo, jat, knguyen, tester |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maurice van der Pot (RETIRED)
2004-05-26 09:13:51 UTC
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. *** |