GDB: Could not load shared library symbols

Question

I'm currently having a look at the Damn Vulnerable Router Firmware, and I'm roughly following the description that is given here:

https://p16.praetorian.com/blog/getting-started-with-damn-vulnerable-router-firmware-dvrf-v0.1

This means I did the following:

• Extracted the firmware with binwalk
• Copied qemu-mipsel-static into the squashfs-root of the extracted firmware
• Emulated the binaries with qemu using chroot, like this:sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof_01 test123
• Started GDB and entered: set architecture mips and target remote 127.0.0.1:1234

When I now continue with c I get:

(gdb) c Continuing. warning: Could not load shared library symbols for 3 libraries, e.g. /lib/libgcc_s.so.1. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? [Inferior 1 (Remote target) exited with code 0101] (gdb) info sharedlibrary No shared libraries loaded at this time.

Although this is only a warning and the debugged program seems to execute just fine, I'm wondering if I actually need to copy some more libraries into my squashfs-root folder in order to get this clean. And if so how do I find out which libraries and where to get them? (info sharedlibrary didn't yield anything)

Answer 1

Typically when cross-debugging a remote target with GDB, you do not try to preserve debug symbols in files loaded onto the target, but rather for reasons of space use only stripped binaries there.

Instead, you keep the versions with symbols intact (and potentially also associated sources) on your PC, and point the debugger at those. If your files with debug symbols on the PC are the ancestors of the stripped files running on the remote target device, then the addresses match and the debugger can use those local files to lookup symbols for the addresses reported by the remote target.

Pointing at local files with debug info is what the hints about "set solib-search-path" or "set sysroot" are suggesting to you, specifically for system libraries used by the program you are debugging. Typically you would also invoke the debugger with a local copy of the program you want to debug, so that it can access the symbols (and perhaps even find the high level sources) of the program as well as the libraries.

That said, this may not be all that relevant to you.

First, debugging the internals of system libraries is rarely interesting, unless you suspect a problem there. Rather, what is interesting is the way in which an application uses system libraries, ie the calls it makes and the results it gets (the same information you might get by running with ltrace interception)

Because dynamic link symbols remain even in stripped executables, a good debugger when properly configured can decode dynamic link symbols and the Procedure Linkage Table (PLT) and identify the dynamic library functions being called, even when you have no other symbols or sources for either the system libraries or the program.