Debugging/tracing inside a shared library during runtime?

views:

419

answers:

+1 Q:

Debugging/tracing inside a shared library during runtime?

Hello everyone,

I'm trying to understand how a certain library works. I've compiled it with my added prinfts and everything is great. Now I want to stop the example program during runtime to look at the call stack, but I can't quite figure out how to do it with gdb. The function I want to break on, is inside a shared library. I've reviewed a previous question here on SO, but the approach doesn't work for me. The language in question is C++. I've attempted to provide the filename and line number, but gdb refuses to understand that, it only lists the source files from the demo app.

Any suggestions?

+3 A:

You can do "break main" first. By the time you hit that, the shared library should be loaded, and you can then set a breakpoint in any of its routines.

Jim Lewis 2009-08-26 21:46:58

Yes, but be sure you compiled that library with -g, and with optimizations turned off!

windfinder 2009-08-26 21:53:56

Unfortunately that didn't help. The function is still not visible, even from main. Is there anything I can add to the code, to cause the execution to stop and drop into the debugger?

EightyEight 2009-08-26 21:57:50

@EightyEight: Hmm, that works for me. Is the library you're trying to debug perhaps dynamically loaded via dlopen()? That might explain why it's still not visible in main. If that's the case, you could set your initial breakpoint after the dlopen call for the target library, then set the final breakpoint. It seems like there should be a simpler way; I'll keep looking.

Jim Lewis 2009-08-26 22:48:59

By the way, in my application, if I try to set the breakpoint in the shared library before entering main(), GDB offers to make the breakpoint pending on future shared library load. But if I accept that, it doesn't seem to resolve the breakpoint, even after the library is loaded. I imagine this is what you're seeing as well?

Jim Lewis 2009-08-26 22:59:19

Yeah, I had to recompile the library with -g. It still doesn't like Class::Function() notation for some reason, but File.cpp:linenumber works like a charm.

EightyEight 2009-08-29 20:34:30

+1 A:

There are two cases to consider (and your question doesn't make it clear which case you have):
- your executable is linked with the shared library directly:
this means that GDB will "see" the symbols (and sources) from shared library when you stop on main
- your executable dynamically loads the shared library (e.g. via dlopen):
in that case, GDB will not "see" your shared library until after dlopen completes.

Since you can't see the symbols when you stop at main, I am guessing you have the second case. You can do "set stop-on-solib-events 1" at the (gdb) prompt, and GDB will stop every time a new shared library is loaded (or unloaded).

You can see which libraries GDB "knows" about via info shared command.
Just wait until you see your target library in that list, before attempting to set breakpoints in it.

Employed Russian 2009-08-29 03:47:47

+1 A:

Check this out:

http://linux.die.net/man/1/ltrace

it will trace your library calls - probably be useful.

And "strace" does the same thing for system calls.

And with that you should be able to find an entry point... You could set a breakpoint in GDB that way (although i can't explain the details myself)

Sean 2009-08-29 03:51:26

ansaurus

tags:

views:

answers:

Debugging/tracing inside a shared library during runtime?

related questions