[llvm-bugs] [Bug 41692] New: -z combreloc sorts only by symbol index, not address

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41692

            Bug ID: 41692
           Summary: -z combreloc sorts only by symbol index, not address
           Product: lld
           Version: unspecified
          Hardware: All
               URL: https://storage.googleapis.com/fuchsia-build/reproduce
                    r/lld-combreloc+comdat.tar.gz
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: roland at hack.frob.com
                CC: jakehehrlich at google.com, llvm-bugs at lists.llvm.org,
                    peter.smith at linaro.org, phosek at chromium.org

The --reproduce tarball at
https://storage.googleapis.com/fuchsia-build/reproducer/lld-combreloc+comdat.tar.gz
demonstrates the issue
with ld.lld from monorepo rev 2efd30571bcc53003376410d4221f7e4dd19f4c3.

In the `readelf -Wr libc.so.debug` output see e.g.:

0000000000385f80  0000026700000001 R_X86_64_64            00000000001a8880
__execvpe + 0
00000000002924f0  0000026700000006 R_X86_64_GLOB_DAT      00000000001a8880
__execvpe + 0

These two relocs have the same symbol index and so are adjacent.  But the one
with the lower r_offset is after the one with the higher offset.

lld sorts only on symbol index (see SyntheticSections.cpp::compRelocations).
The GNU linkers sort for on symbol index, then on reloc address (r_offset).

Gold finally sorts on reloc type, though BFD doesn't.  The comment in Gold's
code seems to suggest that this is just meant to stand in for a stable sort. 
(I don't know why it doesn't just use a stable sort instead.)  Probably that
bit doesn't matter if the sort is stable, and lld uses std::stable_sort for
this already.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190502/4dca5f13/attachment.html>