GDB: Unable to find dynamic linker breakpoint function

by

Need more? See my GDB tutorial: Part 1, Part 2, Part 3.

You all know how much I loooooooove GDB, so what better thing to write about after a long time away?

If you’re seeing this message:

warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

and all your stack frames look like this:

0x40000780 in ?? ()

gdb is trying to tell you that it cannot find the relevant ld library for the target it is debugging.

Huh?

Well, ld (linux-ld.so and ld.so) is responsible for locating and running all the shared libraries required by your executable. You must tell gdb where the target version of ld lives so that it can successfully track what your executable is up to.

You probably already know that when remote debugging you should have an unstripped copy of your target’s root filesystem available on your host. Then you can point gdb to the copy filesystem and it will be able to “see” the target’s files.

And that means a seamless debugging experience 🙂

Since ld is a system library, you needn’t add the path to this explicitly. Just point to the “root” of the copy filesystem and gdb is clever enough to find it.

To do this, use the sysroot command:

set sysroot /absolute/path/to/copy/of/target/root/filesystem

You can also use:

set solib-absolute-prefix /absolute/path/to/copy/of/target/root/filesystem

as this is simply an alias for the sysroot command.

Often you will see suggestions to use:

set solib-search-path /path/to/target/root/filesystem

However, this is checked after sysroot and is meant to be used for a list of colon separated paths to non-system libraries that you may be using on your target.

E.g. If you use a shared library from a third party for say, graphics, that isn’t part of the root filesystem, then you can set its path here.

One more tip:

If you are already connected to the target executable (with the target remote <ip:port> command), when you set your paths, you will get a useful confirmation of the libraries that are loaded on each command:

set sysroot /opt/target/root/
Reading symbols from /opt/target/root/lib/ld-linux.so.3...done. 
Loaded symbols for /opt/target/root/lib/ld-linux.so.3
set solib-search-path /home/faye/LIB/target/ 
Reading symbols from /home/faye/LIB/target/libTerrain.so...(no debugging symbols found)...done.
Loaded symbols for /home/faye/LIB/target/libTerrain.so 
Reading symbols from /home/faye/LIB/target/libAlien.so...done. 
Loaded symbols for /home/faye/LIB/target/libAlien.so

Once you know all your paths are set correctly, you can just add these commands to your GDB init file, to save you typing them in each time you run gdb.

Happy debugging 🙂

Need more? See my GDB tutorial: Part 1, Part 2, Part 3.

 

8 thoughts on “GDB: Unable to find dynamic linker breakpoint function”

  1. I am no stranger to debugging programs, but I am getting familiar, you might call me newbie, to remote debugging host/target, stripped, filesystem, and other clumsy uses of terminology. Is there a good primer for these subjects? Specifically, I want to debug a Sourcery CodeBench workspace executable, that I also have a shared library building in the same workspace. And running into just these type issues. Thank you…

  2. Okay, perhaps dangerously educated now… So do I take it right, that if we have a workspace in $WORKSPACE, we can populate user libraries, like with the shared library scenario, by filling “$WORKSPACE/sysroot/usr/lib” with our SO files? Then tell our tool chain (in this case Sourcery CodeBench) that our host “$WORKSPACE/sysroot” is translated to the target “/”?

  3. I tried the same what you mentioned am getting below error how to solve this.
    Error while mapping shared library sections

  6. Hi
    That’s great explanation.
    I am debugging a core file , and face the same problem after following whatever you mentioned above.
    Where am i heading ? What could be possibly wrong.

    Thanks
    Luv

    • Well… without set-up info I might struggle 😉 Are you debugging a target core file? Or a core file for the same architecture as the platform you are running GDB on? Where and how are you running GDB? On the target? The host?
      Basically, the error means that GDB can’t find linux-ld.so and ld.so for the core file’s target. You need to know a) the target architecture and b) the location of the ld libraries for that architecture. Does that help?

  7. Hello,
    Thanks for your tutorials, I am cross debugging an application on beagleboard and still get “warning: Unable to find dynamic linker breakpoint function.” after applying “set sysroot /home/rifo/projects/gdbFileSystem” where gdbFileSystem contains a copy of my Beagleboard’s filesystem. Do you have an idea what I might be missing?
    Below I write what commands I use

    on TARGET (beagleboard)
    $ gdbserver 192.168.4.133:2222 ./hello_world

    on HOST (PC)
    $arm-none-linux-gnueabi-gdb debug (where debug is the objcopy output of –debug-only part of binary)
    (gdb) set sysroot /home/rifo/projects/gdbFileSystem
    (gdb) target remote 192.168.4.132:2222

    then I get the above mentioned error

    (gdb) info sharedlibrary
    No shared libraries loaded at this time.

Comments are closed.