Target with Debug Symbols
This is the easiest way to work, and it is especially useful when developing one specific shared library.
First, copy the test executable and shared library to the target with debugging information:
Then on target:
gdbserver --multi :1234 ./executable_name
Leading:
arm-linux-gnueabihf-gdb -q -nh \ -ex "target extended-remote target-hostname-or-ip:1234" \ -ex "file ./executable_name" \ -ex 'tb main' \ -ex 'c' \ -ex 'set solib-search-path .'
sharedlibrary libmylib.so also works.
The problem was that gdbserver stopped at the dynamic loader before main , and dynamic libraries were not loading at that moment, and therefore GDB did not know where the characters would still be displayed.
GDB has some mechanisms for automatically loading shared library characters, and if I compile for the host and run gdbserver locally, starting in main not required. But on target ARM is the most reliable thing.
Target gdbserver 7.12-6, host arm-linux-gnueabihf-gdb 7.6.1 from Linaro.
Target libraries without debugging symbols
It is common to deploy target libraries before deploying to embedded objects, since debugging information makes them larger.
For example, Buildroot does this by default, but you can disable it with BR2_STRIP_none=y .
You can define this scenario by doing:
info shared
Which shows something like:
From To Syms Read Shared Object Library 0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*) target:/lib/ld64-uClibc.so.0 0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*) target:/lib/libc.so.0 (*): Shared library is missing debugging information.
so there are asterisks ( * ) for both libraries that say that there is no debugging information.
If so, you need to tell GDB to use shared libraries on the host before removing them.
Buildroot, for example, makes this easy for us, because it maintains a staging directory that contains shared libraries until they are deleted and in the same relative paths as in the target:
set sysroot buildroot/output/staging/
When this option is set, gdb immediately looks for libraries in the host instead of the target and finds /lib/libc.so.0 in the buildroot/output/staging/ + /lib/libc.so.0 :
Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. Reading symbols from buildroot/output/staging/lib/libc.so.0...done.
TODO: I don’t think you can install more than one sysroot , so all of your shared libraries should be placed in their correct relative paths, like in the target image.
If you check the bad default sysroot, you will see:
show sysroot
gives:
target:
which means that gdb by default searches for shared libraries on the target root / .