This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
The stepping problem should be fixed in gdb-4.17. > 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. > [What does this mean?] You have to upgrade ld-linux.so to a newer version to fix this. If you do not want to debug problems in the initialization of global C++ objects, or shared libraries which are accessed via dlopen, you can ignore this message and stick with your current ld-linux.so. > Hi all, > > I realise that this list is mainly concerned with the development of > gdb (good to see things moving forward again), but I've got a query > about gdb and it's (possible) limitations. I was hoping somebody here > could help me out. I've read through the GDB info files and done > various web searches, but to no avail. I expect this is something > specific to ELF shared libs. > > Humour Me :) > > I'm currently trying to develop some additions to various shared > libraries on a Linux ELF system (Kernel 2.0.33, GCC 2.7.2, GDB 4.16, > libc 5.3.12 & binutils 2.7.0), and I'm using GDB to trace through the > calls to the shared libs. > > Now, I can step into the shared library if I've hit a breakpoint in > the application code, but if I hit a breakpoint in the shared lib gdb > will not step into any functions. > > So, do I need to upgrade to 4.17? Is system missing something it > needs to do shared lib debug? or is this just a limitation? > > Below is a session grab. [] denotes my comments. I'm afraid it's a > little over complex, but I believe it shows the problem reasonably > clearly. > > Thanks in advance > > Paul > -- > Paul.Sargent@dial.pipex.com -- Home > Paul.Sargent@3Dlabs.com -- Work > > --------------------------------------------------------------------------- > [3d@stimpy ~/Mesa-3.0]$ gdb demos/multitex > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, Inc... > (gdb) break main > Breakpoint 1 at 0x804b8b0: file multitex.c, line 275. > (gdb) r > Starting program: /home/3d/Mesa-3.0/demos/multitex > 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. > [What does this mean?] > > Breakpoint 1, main (argc=1, argv=0xbffffcc4) at multitex.c:275 > 275 glutInit( &argc, argv ); > (gdb) break __glutSetWindow > [Set breakpoint in the shared lib] > Breakpoint 2 at 0x40026300: file glut_win.c, line 140. > (gdb) cont > Continuing. > > Breakpoint 2, __glutSetWindow (window=0x804df70) at glut_win.c:140 > 140 __glutCurrentWindow = window; > (gdb) list > 135 assumption breaks when GLUT is expected to integrated with > 136 other OpenGL windowing APIs that also make current to > 137 OpenGL contexts. Since glXMakeCurrent short-circuits the > 138 "already bound" case, GLUT avoids the temptation to do so > 139 too. */ > 140 __glutCurrentWindow = window; > 141 > 142 glXMakeCurrent(__glutDisplay, __glutCurrentWindow->renderWin, > 143 __glutCurrentWindow->renderCtx); > 144 > [OK, I'm here. The breakpoint has worked] > (gdb) s > 142 glXMakeCurrent(__glutDisplay, __glutCurrentWindow->renderWin, > [This is a function call to another shared lib. Stepped over] > (gdb) > 152 if (!__glutCurrentWindow->isDirect) > (gdb) > 160 if (__glutDebug) > [This is a function call in the same shared lib. Stepped over] > (gdb) > 162 } > (gdb) > ------------------------------------------------------------------------ > > > -- Peter Schauer pes@regent.e-technik.tu-muenchen.de