> * --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. 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. > /home/bkerin/opt/binutils-2.26/bin/ld.gold: internal error in > init_got_plt_for_update, at target.h:1023 > collect2: error: ld returned 1 exit status > make: *** [instrument_test] Error 1 > 2 $ > > Looking at gold/target.h:1023 it says something about a target needing > to imlement a virtual function to support incremental linking, so > maybe I didn't compile something right? I just built > binutils with ./configure --enable-gold=yes, perhaps something more is > required to support incremental linking? You didn't say what target you're building for, but --incremental currently only works on x86_64. Sorry, there should be a better error message. (I meant to add a target hook to claim support for incremental linking, but kind of forgot.) If you're building for x86_64, please post details on the binutils mailing list. -cary
