https://sourceware.org/bugzilla/show_bug.cgi?id=28849
Bug ID: 28849
Summary: symbol info passed to linker plugin does not include
DT_NEEDED shared libraries
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: sandra at codesourcery dot com
Target Milestone: ---
Created attachment 13948
--> https://sourceware.org/bugzilla/attachment.cgi?id=13948&action=edit
test case script, invoked with compiler pathname as argument
The attached test case from Joseph Myers reproduces a bug originally seen by a
customer who is trying to use LTO on a much larger application. Working
backwards through the symptoms, the error is that LTO is optimizing away the
definition of should_be_dynamic_in_exec. It is doing that because ld is
passing incorrect symbol resolution info to the LTO plugin and it doesn't know
that symbol is referenced externally. And it's getting incorrect symbol
resolution info because plugin_call_all_symbols_read() is getting called before
the ELF emulation's after_open hook adds DT_NEEDED dependencies to the link.
Judging by the comments in the code (lang_process() in ldlang.c), this ordering
was deliberate.
My idea for fixing this is to split the add-more-files-to-the-link part of the
after_open hook into a separate hook that runs both before handing things off
to the plugin, and after in case the plugin has added its own new things to the
link with further library dependencies. The new hook would have to be
idempotent (I suspect the other things the after_open hook may be doing are
not). But, I don't have much background on the plugin API... is this a
reasonable approach to solving the problem, or is there a better idea I should
pursue instead?
--
You are receiving this mail because:
You are on the CC list for the bug.
