Linux – Debugging shared libraries remotely with gdb/gdbserver

armgdblinuxremote-debuggingshared-libraries

My question is about remote debugging an application on an embedded arm processor using gdb/gdbserver.

I can debug the application itself, but the application dynamically links to a shared library which implements an in house communications protocol. I want to be able to set breakpoints within the shared library functions so try to figure out some device discovery problems.

I have made sure that the library is compiled with debug symbols and is loaded by gdb on the host side, I can list functions within the library and even set the breakpoints but as soon as I try to run the application I get an error message to the effect of:

Cannot insert breakpoint X. Error accessing memory address : Input/output error.

where X is the breakpoint number in gdb and is an address far to small to be valid.
I am using the new library on both the target and the host machine, but via mount -o bind newlib oldlib on the target from an nfs mount.
Does anyone have an idea about what could be wrong?
Thanks in advance.

Best Answer

I see this question is from 2009, but the current answers are out-of-date, so here's an update:

@Employed Russian suggested that you must use stop-on-solib-event. This is no longer true; NDK r8d supports pending breakpoints in yet-to-be-loaded solibs.

@Brent Piddy says that stop-on-solib-event doesn't work with gdbserver. This is also no longer true since at least r8c. My company has a product that relies on this NDK behavior from GDB, we would be in big trouble without it.

Related Solutions

C++ – How to set breakpoints on future shared libraries with a command flag

Replying to myself, I'd like to give the answer that someone gave me on IRC:

(gdb) apropos pending
actions -- Specify the actions to be taken at a tracepoint
set breakpoint -- Breakpoint specific settings
set breakpoint pending -- Set debugger's behavior regarding pending breakpoints
show breakpoint -- Breakpoint specific settings
show breakpoint pending -- Show debugger's behavior regarding pending breakpoints

And so set breakpoint pending on does the trick; it is used in cmds.gdb like e.g.

set breakpoint pending on
break <source file name>:<line number>

C++ – Difference between static and shared libraries

Shared libraries are .so (or in Windows .dll, or in OS X .dylib) files. All the code relating to the library is in this file, and it is referenced by programs using it at run-time. A program using a shared library only makes reference to the code that it uses in the shared library.

Static libraries are .a (or in Windows .lib) files. All the code relating to the library is in this file, and it is directly linked into the program at compile time. A program using a static library takes copies of the code that it uses from the static library and makes it part of the program. [Windows also has .lib files which are used to reference .dll files, but they act the same way as the first one].

There are advantages and disadvantages in each method:

Shared libraries reduce the amount of code that is duplicated in each program that makes use of the library, keeping the binaries small. It also allows you to replace the shared object with one that is functionally equivalent, but may have added performance benefits without needing to recompile the program that makes use of it. Shared libraries will, however have a small additional cost for the execution of the functions as well as a run-time loading cost as all the symbols in the library need to be connected to the things they use. Additionally, shared libraries can be loaded into an application at run-time, which is the general mechanism for implementing binary plug-in systems.
Static libraries increase the overall size of the binary, but it means that you don't need to carry along a copy of the library that is being used. As the code is connected at compile time there are not any additional run-time loading costs. The code is simply there.

Personally, I prefer shared libraries, but use static libraries when needing to ensure that the binary does not have many external dependencies that may be difficult to meet, such as specific versions of the C++ standard library or specific versions of the Boost C++ library.

Related Topic