[PATCH] D68094: ELF: Don't merge SHF_LINK_ORDER sections in relocatable links.
Peter Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 26 18:00:42 PDT 2019
peter.smith added a comment.
I've got a test case that certainly doesn't work well when doing a -r, and then relinking the corresponding object.
exidx.s
.section .text.f1,"ax",%progbits
.globl f1
.type f1, %function
f1: .fnstart
.cantunwind
bx lr
.fnend
.section .text.f2,"ax",%progbits
.globl f2
.type f2, %function
f2: .fnstart
bx lr
.save {r7, lr}
.setfp r7, sp, #0
.fnend
exidx2.s
.section .text.f1,"ax",%progbits
.globl f3
.type f3, %function
f3: .fnstart
.save {r7, lr}
.setfp r7, sp, #0
bx lr
.fnend
.section .text.f2,"ax",%progbits
.globl f4
.type f2, %function
f4: .fnstart
.cantunwind
bx lr
.fnend
.text
.globl __aeabi_unwind_cpp_pr0
__aeabi_unwind_cpp_pr0: bx lr
exidx.lds
SECTIONS {
.foo : { *(.text.f2) *(.text.f1) }
}
Commands
clang --target=armv7a-linux-gnu exidx.s exidx2.s -c
ld.lld exidx.o exidx2.o -r -o exidxr.o -T exidx.lds
ld.lld exidxr.o -o exidx.exe
The creation of the relocatable object produces a single output section with 4 .ARM.exidx sections with a SHF_LINK_ORDER dependency on it. The linker script scrambles the order of the .text.f* functions so that it doesn't match the order of the functions in the output executable section. This will break a linker using SHF_LINK_ORDER to construct the table.
In lld it is worse as there is custom code that is expecting a 1:1 mapping between .ARM.exidx and executable section. Looking at the ARMExidxSyntheticSection::finalizeContents() the code frequently goes from the executable section back to its SHF_LINK_ORDER section (first .ARM.exidx in the dependent sections). This doesn't work well when there are multiple .ARM.exidx sections on the dependent sections list.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68094/new/
https://reviews.llvm.org/D68094
More information about the llvm-commits
mailing list