Using gdb to convert addresses to lines

Question

I have a stack trace generated by a stripped application which looks like this:

 *** Check failure stack trace: ***     @     0x7f0e442d392d  (unknown)     @     0x7f0e442d7b1f  (unknown)     @     0x7f0e442d7067  (unknown)     @     0x7f0e442d801d  (unknown)     @     0x7f0e457c55e6  (unknown)     @     0x7f0e457c5696  (unknown)     @           0x4e8765  (unknown)     @           0x4a8b43  (unknown)     @     0x7f0e43197ced  (unknown)     @           0x4a6889  (unknown) 

And I have a non-stripped version of the executable and all of its libraries ( compiled with debug information). But how can I translate the address into files and line numbers??

Here is what I have tried:

gdb set solib-absolute-prefix /path/to/non-stripped/edition/of/root/filesystem/sysroot/ file /path/to/non-stripped/edition/of/root/filesystem/sysroot/usr/bin/my-buggy-app info line *0x7f0e457c5696 

When I type in the file command it only loads symbols from the file, not all the libraries which are used. Is there a way this can be done?

The "info line" command says:

No line number information available for address 0x7f0e442d801d

Which I assumes is because the address is in one of the shared libraries, but how can I know in which one of them?

Answer 1

Per the OP, the command in GDB to find the source line of code from an address is:

info line *0x10045740 

Edit: Replaced "info symbol 0x10045740" which won't work under certain conditions (thanks @Thomasa88).

Answer 2

But how can I translate the address into files and line numbers?

For the main executable (addresses like 0x4e8765) do this:

addr2line -e /path/to/non-stripped/.../my-buggy-app \     0x4a6889 0x4a8b43 0x4e8765 

Actually, you might want to subtract 5 (usual length of the CALL instruction) from all of the above addresses.

For the addresses in shared libraries, you have to know the load address of the library.

If your application produced a core file, then (gdb) info shared will tell you where libraries were loaded.

If you did not get a core file, and the application did not print the required mapping, then

• you should fix the application so it does print that info (the stack trace is mostly useless without it), and
• you could still guess: look at the code in the executable at 0x4e8760 -- it should be a CALL instruction to some function. Now find out which library that function is in, and find its address in the library (via nm). If you are lucky, that address is near 0xNc56NN. You can now guess the load address of whatever library is at 0x7f0e457NNNNNN. Repeat for 0x7f0e457c55e1, and you can find out the load address of library at 0x7f0e442dNNNN.