Bug 19872 - nm and probably addr2line can't handle binaries produced with gold --incremental
Summary: nm and probably addr2line can't handle binaries produced with gold --incremental
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.26
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-26 23:24 UTC by Britton Kerin
Modified: 2016-04-06 08:02 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Proposed patch (802 bytes, patch)
2016-03-30 12:42 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Britton Kerin 2016-03-26 23:24:44 UTC
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 <ccoutant@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.
Comment 1 Nick Clifton 2016-03-29 10:26:38 UTC
Hi Guys,

 Could somebody upload a (small) test case please ?

Cheers
  Nick
Comment 2 Britton Kerin 2016-03-29 19:44:51 UTC
$ cat test.c
int
main (void)
{
  return 0;
}
$ gcc -Wall -Wextra -Werror -g -c test.c -o test.o
$ rm -f test && gcc -fuse-ld=gold -Wl,--incremental test.o -o test
test: stat: No such file or directory
linking with --incremental-full
$ nm --line-numbers 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.
$
Comment 3 Nick Clifton 2016-03-30 12:42:58 UTC
Created attachment 9142 [details]
Proposed patch

Hi Britton,

  Please could you try out this patch and let me know how you get on.

Cheers
  Nick
Comment 4 Britton Kerin 2016-03-31 20:06:20 UTC
It makes the warnings go away.  Caveats:

* My use case at the moment isn't that much more extensive than the test case I provided.

* I haven't tested if this fixes things for addr2line (if it's meant to).  Cary
seemed to think the same issue would apply there.

* The patch doesn't look like it's doing what Cary thought would be needed at the end of his comment.
Comment 5 Britton Kerin 2016-03-31 21:09:30 UTC
I asked Cary to take a look at this bug, and he said:

> It's ok for now, but it'll take a bit more to really support incremental linking. I'll try to work on it sometime.
Comment 6 Sourceware Commits 2016-04-04 11:55:08 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=67f101eece4327a7c9e13f257fe76f8082a5e336

commit 67f101eece4327a7c9e13f257fe76f8082a5e336
Author: Nick Clifton <nickc@redhat.com>
Date:   Mon Apr 4 12:53:33 2016 +0100

    Ignore DWARF debug information with a version of 0 - assume that it is padding.
    
    	PR 19872
    bfd	* dwarf2.c (parse_comp_unit): Skip warning about unrecognised
    	version number if the version is zero.
    
    bin	* dwarf.c (display_debug_aranges): Skip warning about unrecognised
    	version number if the version is zero.
Comment 7 Nick Clifton 2016-04-04 11:57:33 UTC
Patch checked in.

If the problem resurfaces, then please reopen this PR.

Cheers
  Nick
Comment 8 gingold@adacore.com 2016-04-04 12:01:58 UTC
Nick,

you have committed unrelated chunks (pe-dll, aarch64/simulator.c)

Tristan.
Comment 9 Nick Clifton 2016-04-05 14:05:52 UTC
Hi Tristan,

> you have committed unrelated chunks (pe-dll, aarch64/simulator.c)


Argh!  Why does git do this ?  I am sure that I only "git add"ed the 
changes the bfd/ directory, so why did it add the others ?

This is really starting to piss me off.. :-(

Oh well.  Do you know how I can partially undo a commit ?

Cheers
  Nick
Comment 10 gingold@adacore.com 2016-04-06 07:12:27 UTC
> On 05 Apr 2016, at 16:05, nickc at redhat dot com <sourceware-bugzilla@sourceware.org> wrote:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19872
> 
> --- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
> Hi Tristan,
> 
>> you have committed unrelated chunks (pe-dll, aarch64/simulator.c)
> 
> 
> Argh!  Why does git do this ?  I am sure that I only "git add"ed the 
> changes the bfd/ directory, so why did it add the others ?
> 
> This is really starting to piss me off.. :-(

Mistakes happen :-(

> Oh well.  Do you know how I can partially undo a commit ?

I think it’s over.
Anyway, I see you already committed the ChangeLog for the other chunks.


Tristan.
Comment 11 Andreas Schwab 2016-04-06 08:02:55 UTC
> Argh!  Why does git do this ?  I am sure that I only "git add"ed the 
> changes the bfd/ directory, so why did it add the others ?

Instead of creating partial commits you should consider working on a branch.