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]

Re: Tracing ELF shared libs.


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