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


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

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)

  • Hi and welcome to RE.SE. It'll really be hard to help you unless you provide a little more context and pinpoint exactly the question you have. Right now this is fairly broad.
    – 0xC0000022L
    Commented Mar 17, 2019 at 19:40
  • 1
    Hi, thanks for welcoming me here. I actually like Chris Stratton's response, so I'll probably just leave the question as it is, if this is ok.
    – Lord Vapor
    Commented Mar 18, 2019 at 18:40

1 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.

  • Thanks for the detailed answer. This is exactly the background info I wanted to have on this topic.
    – Lord Vapor
    Commented Mar 18, 2019 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.