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

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de ---
On Wed, 19 Aug 2015, ccoutant at gmail dot com wrote:

> 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/ : { *(*) }
> }

Ah, great - that indeed makes it work (thanks for the --debug=script
hit as well).

> >> 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.

Indeed.  Confuses the GCC testsuite and is mildly annoying but
well ... GNU ld behaves the same way.

> > 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 it's because it creates the relocation section but then
the input for .debug_info is marked with SFH_EXCLUDE and things
fall apart then.

> > 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.

Indeed, I am not suggesting to extend the scripting language.  But
if gold would accept a script like above (with INPUT(t.o) added)
as output from the linker plugin it could special-case that path
and ignore SHF_EXCLUDE.  It could also ignore __gnu_lto_slim and
avoid giving the warning.  And we'd save the intermediate I/O as well ...

That's kind-of extending the plugin API.  You could as well extend it
in a more traditional way rather than via a script output, like
adding a way for the plugin to call back into the linker to tell it
to preserve and rename some sections from the original linker input
files.  But the scripting way looks so appealing to me ;)

Richard.

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