gnu_debuglink support broken

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Build an executable or shared library, then perform the following commands:

    objcopy --only-keep-debug foo.so foo.so.debug
    objcopy --strip-debug foo.so
    objcopy --add-gnu-debuglink=foo.so.debug foo.so

This results in a stripped binary and an accompanying ".debug" file containing 
symbols. You can debug the binary in GDB and its symbols will be found in the 
.debug file.

2. Attempt to dump symbols with the following command:

    dump_syms foo.so . > foo.so.sym

What is the expected output? What do you see instead?

The external symbols file will not be found. The resulting symbol file will be 
identical to a symbol file generated from a binary built without symbols.

This is happening because LoadSymbols returns true if it finds a .gnu_debuglink 
section in the ELF, but ReadSymbolDataElfClass will only actually load symbols 
from the debuglink if LoadSymbols returns false (dump_symbols.cc:840).

I've attached a patch which fixes this. With the patch is applied, debuglink 
symbols are loaded if LoadSymbols returns true and there are characters in 
info.debuglink_file(), which is only the case if a) there are no embedded 
symbols and b) there is data in the .gnu_debuglink section of the binary.

What version of the product are you using? On what operating system?

SVN latest, Ubuntu 14.04 LTS

Original issue reported on code.google.com by tom.edwa...@thefoundry.co.uk on 14 Jan 2015 at 12:07

Attachments:

• breakpad_debuglink.patch

[GoogleCodeExporter]

Please give r1422 or newer a try. It should be fixed.

Original comment by thestig@chromium.org on 5 Feb 2015 at 11:07

[GoogleCodeExporter]

This fixes the issue I originally described, but on closer inspection things 
are still broken.

I created a very simple test program and compared the results of nm and 
dump_syms on two builds, one with embedded symbols and another with linked 
symbols. The results:

nm symbols_test -l | wc -l
37
nm symbols_test_linked -l | wc -l
37

dump_syms symbols_test | wc -l
46
dump_syms symbols_test_linked | wc -l
29

Both dump_syms and nm produce correct results for the binary with embedded 
symbols. But when given a file with linked symbols, dump_syms doesn't output 
any FILE or FUNC data. That's why its output is 17 lines shorter.

nm output is identical for both files.

Original comment by tom.edwa...@thefoundry.co.uk on 6 Feb 2015 at 11:02

[GoogleCodeExporter]

Given symbols_test_linked, and the debugging symbols for symbols_test_linked as 
/path/to/foo/symbols_test_linked.debug, you need to run:

dump_syms symbols_test_linked /path/to/foo

The .gnudebuglink section in symbols_test_linked only contains a file name and 
checksum. You need to pass the directories to search to dump_syms.

Original comment by thestig@chromium.org on 6 Feb 2015 at 11:53

[GoogleCodeExporter]

Gets me every time! dump_syms really ought to automatically handle symbols 
being in the same directory as the binary...

This bug is fixed.

Original comment by tom.edwa...@thefoundry.co.uk on 9 Feb 2015 at 10:26

[GoogleCodeExporter]

For /path/to/file, it looks like gdb tries:
- /path/to/file.debug
- /path/to/.debug/file.debug
- /usr/lib/debug/path/to/file.debug

I suppose dump_syms can do the same.

Original comment by thestig@chromium.org on 9 Feb 2015 at 7:43

• Changed state: Fixed

[GoogleCodeExporter]

For the record, the fix is r1422.

Original comment by thestig@chromium.org on 9 Feb 2015 at 7:44

[GoogleCodeExporter]

For the dump_syms enhancement, see bug 636.

Original comment by thestig@chromium.org on 10 Feb 2015 at 2:48