CODEWITHSUNDEEP
debugginglinkergdbdebug-symbolsnm
nonot1
nonot1

Reputation: 2828

debug binary: How to dump which .a/.o each symbol came from?

I've got a debug-enabled binary, the collection of .a files it was statically linked with, and the source for everything.

How can I get a parse-able dump that lists each symbol name in the final executable binary, and which .a and .o it came from? (Plus the original .c/.cpp file, if possible.)

There are a series of cross-dependencies, circular-dependencies, and even a few multiple defined symbols in the libraries that I'm trying to map out with the eventual goal to recreate the build system. Somehow the old build system managed to get everything linked together. (More by accident than by design i think...)

So far, I've tried various invocations of nm but can't quite seem to get this data. Perhaps nm is the wrong tool.

Upvotes: 0

Views: 1365

Answers (1)

Employed Russian
Employed Russian

Reputation: 213935

By the time final binary is linked, the info on which symbol came from which .o or .a is lost.

Since you have the debug info available, you can know the source of each symbol, and that may help you reconstruct the lost info (or not: if foo.c is compiled into foo1.o, foo2.o and foo3.o (e.g. with different -DFOO=1, etc. flags), and then stuffed into different archive libraries, then there is no easy way to tell which object contributed the symbol to the final binary. Hopefully your old build system was not that bad.

So,

# list of global symbols and their addresses
nm a.out | egrep ' [TDW] '

# dump source for every symbol
addr2line a.out < /list/of/addresses/from/above

# list all objects in all libraries
ar t *.a

Now you have enough info to map majority of symbols to the objects they came from. There will probably be <= 10% of sources where source file name doesn't match object file name. These you'd have to resolve by hand.

Upvotes: 1

Related Questions