bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/28849] New: symbol info passed to linker plugin does not include


From: sandra at codesourcery dot com
Subject: [Bug ld/28849] New: symbol info passed to linker plugin does not include DT_NEEDED shared libraries
Date: Tue, 01 Feb 2022 20:43:13 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]