Search code examples
debugginggdbshared-librariesremote-debugginggdbserver

GDB remote debugging: influences on execution on remote target

Background

I am working with an ARM device using a custom-built toolchain (based on Yocto with gcc 4.7 and gdb 7.5) and make use of remote gdb debugging with Eclipse CDT as debugger frontend. Recently I had the issue that I could not debug a particular executable on the remote target due to this error (reported by the gdbserver on the target) that occurred immediately when the host gdb connected to the target:

error while loading shared libraries: unexpected PLT reloc type 0xf0

I could finally track down the issue to mismatching binaries of the dynamic linker library /lib/ld-2.16.so on the target and on the host, where, by calling set sysroot in gdb, I used a locally stored root directory of the target that is generated along with the toolchain.

Keeping the local file in sync with the remote file works, but I could also just omit setting the sysroot in order to debug at least the executable itself. This leads me to the following

Question

How does the usage of a wrong ld.so binary on the debugging host influence the execution of the application within gdbserver on the target? I would rather expect that I get just wrong debug information on the host as the executable runs without problems on the target (within gdbserver) if I have no ld.so present at all on the host. But as the behavior is different, it seems that there is some feedback from the host to the target when the file is available.

Solution

  • How does the usage of a wrong ld.so binary on the debugging host influence the execution of the application within gdbserver on the target?

    Good question.

    One possible explanation: in order to properly keep track of e.g. loaded shared libraries on the target, GDB sets a number of internal breakpoints (these are visible in maintenance info breakpoints output -- they have negative breakpoint number).

    When you don't supply a local file at all, GDB has no idea where to set these breakpoints, and so it doesn't (you can't e.g. debug library initializers without them).

    When you supply an incorrect local file, GDB does set the breakpoint ... in the wrong place (by overwriting what GDB thinks is an instruction, but what in reality is a PLT relocation). When the loader then encounters this overwritten relocation, it complains.