[Bug gold/18837] gold does not handle linker-scripts with inputs

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18837

--- Comment #4 from Cary Coutant <ccoutant at gmail dot com> ---
> I see.  So I'm trying (same input):
>
> SECTIONS {
>   .debug_info 0 : { *(.gnu.lto_.debug_info*) }
>   .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
>   .debug_str 0 : { *(.gnu.lto_.debug_str*) }
>   /DISCARD/ : { *(*) }
> }
>
>> ld.gold -o x -T script t.o -r
> Segmentation fault

Hmm. This seems to be due to the fact that gold is trying to create
relocation sections for each of the new sections, but the script is
preventing it from doing so (add --debug=script to see it complain
about sections it's prevented from creating). Then we go on and assume
that we have a valid output section for the relocations and end up
segfaulting when we try to dereference the null pointer. Two bugs: (a)
gold should not let the /DISCARD/ clause prevent it from creating
relocation sections; and (b) it should be more careful to assert that
the pointer is not null before dereferencing.

I think you can get it to work by adding additional section
specifications something like this:

SECTIONS {
  .debug_info 0 : { *(.gnu.lto_.debug_info*) }
  .debug_abbrev 0 : { *(.gnu.lto_.debug_abbrev*) }
  .debug_str 0 : { *(.gnu.lto_.debug_str*) }
  .rela.debug_info 0 : { *(.rela.debug_info) }
  .rela.debug_abbrev 0 : { *(.rela.debug_abbrev) }
  .rela.debug_str 0 : { *(.rela.debug_str) }
  /DISCARD/ : { *(*) }
}

>> ld.gold -o x -T script t.o
> t.o: plugin needed to handle lto object

That's just a (hopefully) helpful message we print when we see the
symbol "__gnu_lto_slim". It's informational only.

> ld.gold: internal error in address, at ../../gold/output.h:72

Not sure what this is caused by. I'm not seeing it with a top-of-trunk
linker. (But I'm also trying a much simpler test case, so maybe I
haven't recreated your scenario closely enough.)

> maybe you can help me writing a linker script that works with GOLD and
> a partial link (and also suggest how to drop the 'E'xclude bit during
> that link)?  golds "error" messages are not exactly helpful :/

Sorry, can't help you with the SHF_EXCLUDE flag. There's no way that I
know of today to have the linker ignore that flag. Doing this will
probably require additional support in the linker(s), which would
probably be best done via an extension to the plugin API rather than
the scripting language.

-cary

-- 
You are receiving this mail because:
You are on the CC list for the bug.