aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/XCOFFObjectFile.cpp
diff options
context:
space:
mode:
authorFangrui Song <maskray@google.com>2020-08-14 10:23:45 -0700
committerFangrui Song <maskray@google.com>2020-08-17 11:29:05 -0700
commite8a11c0558af93182ca03c1afcdb857394955767 (patch)
tree90bff6b911841acf70abf14cf34678804d2a886c /llvm/lib/Object/XCOFFObjectFile.cpp
parent69721fc9d1b5df9a7a32d2fee6d72c8c7c9bf644 (diff)
downloadllvm-e8a11c0558af93182ca03c1afcdb857394955767.zip
llvm-e8a11c0558af93182ca03c1afcdb857394955767.tar.gz
llvm-e8a11c0558af93182ca03c1afcdb857394955767.tar.bz2
[ELF] Allow mixed SHF_LINK_ORDER & non-SHF_LINK_ORDER sections and sort within InputSectionDescription
LLD currently does not allow non-contiguous SHF_LINK_ORDER components in an output section. This makes it infeasible to add SHF_LINK_ORDER to an existing metadata section if backward compatibility with older object files are concerned. We did not allow mixed components (like GNU ld) and D77007 relaxed to allow non-contiguous SHF_LINK_ORDER components. This patch allows arbitrary mix, with sorting performed within an InputSectionDescription. For example, `.rodata : {*(.rodata.foo) *(.rodata.bar)}`, has two InputSectionDescription's. If there is at least one SHF_LINK_ORDER and at least one non-SHF_LINK_ORDER in .rodata.foo, they are ordered within `*(.rodata.foo)`: we arbitrarily place SHF_LINK_ORDER components before non-SHF_LINK_ORDER components (like Solaris ld). `*(.rodata.bar)` is ordered similarly, but the two InputSectionDescription's don't interact. It can be argued that this is more reasonable than the previous behavior where written order was not respected. It would be nice if the two different semantics (ordering requirement & garbage collection) were not overloaded on one section flag, however, it is probably difficult to obtain a generic flag at this point (https://groups.google.com/forum/#!topic/generic-abi/hgx_m1aXqUo "SHF_LINK_ORDER's original semantics make upgrade difficult"). (Actually, without the GC semantics, SHF_LINK_ORDER would still have the sh_link!=0 & sh_link=0 issue. It is just that people find the GC semantics more useful and tend to use the feature more often.) GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=16833 Differential Revision: https://reviews.llvm.org/D84001
Diffstat (limited to 'llvm/lib/Object/XCOFFObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions