[Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local

[address@hidden]

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

Maciej W. Rozycki <address@hidden> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[MIPS] produces invalid     |GC-ed DSO symbols make
                   |dynamic symbol table when   |corresponding symbols
                   |--gc-sections is used since |defined by a linker script
                   |PR ld/13177 fix             |local

--- Comment #17 from Maciej W. Rozycki <address@hidden> ---
I've got down to the bottom of this issue now and as it turns out our
initial understanding was completely wrong.

The real issue is the presence of unused (and GC-ed) symbols in a DSO
used in a link makes identically named symbols ordinarily defined (not
hidden or PROVIDEd) by a linker script local, even though the latter
symbols are supposed to be global as if no DSO defined them as well.  So
rather than removing the local entries made in the dynamic symbol table
produced we actually need to make them global.  See
<https://sourceware.org/ml/binutils/2017-01/msg00263.html> for the full
analysis, proposed patch, test cases and results.

The issue applies to our all ELF targets with DSO support and the outcome
just happens to hurt MIPS binaries in the most spectacular way, due to
this target psABI's peculiarity and our handling of it, by making any
affected binaries produced invalid, in addition to being incorrect as
with the remaining ELF targets.

Regardless I have made a MIPS dynamic symbol table sorting update in case
we have a valid reason sometime to have (non-section) local entries
there.  This turned out simpler than I had thought as by the time
`mips_elf_sort_hash_table' is called all the necessary information has
already been gathered by the generic ELF linker and the MIPS backend, as
applicable.  So all that has to be done is using it properly to assign
final indices.

With the fix for this issue in place the problematic case of dynamic
symbol table sorting cannot be triggered however, so no test case is
possible, and I will be only pushing the sorting change, along with a
couple of preparatory clean-ups to code affected, to our master branch,
with no backport to 2.28 planned.

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