GDB: Unable to find dynamic linker breakpoint function

Need more? See my GDB tutorial: Part 1Part 2Part 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.


Well, ld ( and 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/ 
Loaded symbols for /opt/target/root/lib/
set solib-search-path /home/faye/LIB/target/ 
Reading symbols from /home/faye/LIB/target/ debugging symbols found)...done.
Loaded symbols for /home/faye/LIB/target/ 
Reading symbols from /home/faye/LIB/target/ 
Loaded symbols for /home/faye/LIB/target/

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.


Find Files Installed by Yum

Yum is great isn’t it? All you do is tell it the name of the program or library and off it goes, installing files all over your computer, ready for you to use at the drop of a hat.

However, sometimes it’s nice to know a little bit more about what yum is up to. Have you ever found yourself hunting all over your hard drive, trying to find exactly where yum has installed something?

Me too.

Well, if you do ever need to quiz yum, the following commands will allow you to gather all the knowledge you need on what your latest install has done.

As with pretty much everything on Linux, yum keeps a record of what it does. This record lives in:


So you could take a look in this file and see what packages were installed on what date.

But wait!

Yum itself has a history command, so you can also see this information in a much prettier way by typing:

yum history

yum history

And then using the ID in the left column to get more information about each record:

yum history info 24

Finally, and most importantly, what if you need to know where yum has installed all the files from your latest update?

Well, yum uses rpm for installation, so you can use it to query the package, like this:

rpm -ql eclipse-cdt

Which will give you a list of the full path to every file that was installed onto your computer for the package in question (I’ve used eclipse-cdt, but obviously you can ask it about anything you’ve installed).


The Biggest Programming Mistake I Ever Made

Well folks, as mentioned in How To Learn From Your Programming Mistakes, here it is.

The story that still makes me shudder when I think about it.

When it comes to all time, super-duper cock-ups, this is one I will never forget.

Strictly speaking I wasn’t actually trying to program anything when it happened. I was trying to…

Oh let’s just start from the beginning shall we?

The danger of embedded systems

Not long out of university, I was working on an embedded linux platform. The embedded OS, or target, was accessed via telnet from Linux desktop machines. At any one time your terminal window could be logged into your desktop, or into the embedded Linux platform (can you see where this is going?).

I was asked to help out a colleague who was having trouble getting his target up and running.

He pointed me to his machine in the lab, and then disappeared, leaving me to it.

Straight away I could see that the embedded board he was using was in a mess. Files were missing, some were corrupt, and it was basically unrecoverable.

I had several terminal windows open at the same time, and I was switching rapidly between them to check build version, firmware version, and to access my own machine remotely. I downloaded the latest build from my machine and logged into the target to reinstall it.

At least, I thought I did.

I typed:

rm -rf /

to delete everything, so I could start the install from scratch[1].

But as I pressed the return key, I realised I was using the terminal window for his desktop machine.

And I was logged in as root.

If I had to describe that moment using a movie scene, it would look like this[2]:



I cancelled the process immediately, but it was too late. I had totally destroyed his filesystem. Now he had no target and no desktop computer either.

What did I do?

After I’d finished reeling from the massive mistake I’d just made, I gathered myself together, went to find my poor victim and confessed.

And apologized.

A lot.

He very graciously took it in his stride (since there was bugger all he could do about it, I guess), and seemed happy enough once I promised I would immediately reinstall his operating system AND fix the target, as I had originally intended.

Now, to save face (and enhance my career prospects), I suppose I could have done the reinstall in secret, and feigned ignorance if he had asked where his local files had gone.

But I owned up, and it wasn’t as bad as I thought it would be.

And now I can laugh about it (just).

And of course, I have NEVER made the same mistake again.


[1] The command I used, for those of you that aren’t familiar with Linux, is the equivalent of selecting your hard drive and pressing the delete key.

[2] Jaws contains a classic example of the Dolly Zoom: that wonderfully abused effect where the background moves away while the actor appears to loom larger, usually accompanied by some tense string music.