https://sourceware.org/bugzilla/show_bug.cgi?id=19872
Bug ID: 19872
Summary: nm and probably addr2line can't handle binaries
produced with gold --incremental
Product: binutils
Version: 2.26
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: britton.kerin at gmail dot com
Target Milestone: ---
I originally reported:
> * --incremental gold produces binaries st nm --line-numbers complains like
> this:
>
> $ nm --line-numbers instrument_test >/dev/null
> nm: Dwarf Error: Bad abbrev number: 0.
> nm: Dwarf Error: found dwarf version '0', this reader only
> handles version 2, 3 and 4 information.
> nm: Dwarf Error: found dwarf version '0', this reader only
> handles version 2, 3 and 4 information.
>
> nm still coughs up the requested information but these are pretty
> disturbing warnings.
Cary Coutant <ccout...@gmail.com> helpfully commented:
Gold adds padding to most sections during the first (full) incremental link.
For .debug_info sections, it makes the padding look like an empty compilation
unit, but other sections just get padded with zeroes. I believe nm here is
trying to read the .debug_line section, assuming that it consists of one
compilation unit after another. The padding is at the end, so it's already
found what it needs to by the time it prints those messages. To work with
incremental linking, nm (and addr2line) will probably have to start with the
.debug_info section, which has pointers to each compilation unit's line number
table.
It would be nice if nm and addr2line worked correctly with gold --incremental,
as all of these are very useful during development.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
