[Bug binutils/19872] New: nm and probably addr2line can't handle binaries produced with gold --incremental

[britton.kerin at gmail dot com]

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 <address@hidden> 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.