https://sourceware.org/bugzilla/show_bug.cgi?id=20828
Maciej W. Rozycki <ma...@linux-mips.org> 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 <ma...@linux-mips.org> --- 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils