maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/linkorder-mixed.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

49 lines
1.5 KiB
ArmAsm
Raw Normal View History

[ELF][test] Add REQUIES: x86 and -triple=x86_64 to linkorder-mixed.s
2020-08-06 07:28:44 +08:00
# REQUIRES: x86
[ELF] Allow SHF_LINK_ORDER sections to have sh_link=0 Part of https://bugs.llvm.org/show_bug.cgi?id=41734 The semantics of SHF_LINK_ORDER have been extended to represent metadata sections associated with some other sections (usually text). The associated text section may be discarded (e.g. LTO) and we want the metadata section to have sh_link=0 (D72899, D76802). Normally the metadata section is only referenced by the associated text section. sh_link=0 means the associated text section is discarded, and the metadata section will be garbage collected. If there is another section (.gc_root) referencing the metadata section, the metadata section will be retained. It's the .gc_root consumer's job to validate the metadata sections. # This creates a SHF_LINK_ORDER .meta with sh_link=0 .section .meta,"awo",@progbits,0 1: .section .meta,"awo",@progbits,foo 2: .section .gc_root,"a",@progbits .quad 1b .quad 2b Reviewed By: pcc, jhenderson Differential Revision: https://reviews.llvm.org/D72904
2020-08-06 07:09:41 +08:00
## Test that we allow SHF_LINK_ORDER sections with sh_link=0.
## SHF_LINK_ORDER sections with sh_link!=0 are ordered before others.
[ELF][test] Add REQUIES: x86 and -triple=x86_64 to linkorder-mixed.s
2020-08-06 07:28:44 +08:00
# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
[ELF] Allow SHF_LINK_ORDER sections to have sh_link=0 Part of https://bugs.llvm.org/show_bug.cgi?id=41734 The semantics of SHF_LINK_ORDER have been extended to represent metadata sections associated with some other sections (usually text). The associated text section may be discarded (e.g. LTO) and we want the metadata section to have sh_link=0 (D72899, D76802). Normally the metadata section is only referenced by the associated text section. sh_link=0 means the associated text section is discarded, and the metadata section will be garbage collected. If there is another section (.gc_root) referencing the metadata section, the metadata section will be retained. It's the .gc_root consumer's job to validate the metadata sections. # This creates a SHF_LINK_ORDER .meta with sh_link=0 .section .meta,"awo",@progbits,0 1: .section .meta,"awo",@progbits,foo 2: .section .gc_root,"a",@progbits .quad 1b .quad 2b Reviewed By: pcc, jhenderson Differential Revision: https://reviews.llvm.org/D72904
2020-08-06 07:09:41 +08:00
# RUN: ld.lld %t.o -o %t
# RUN: llvm-readelf -S -x .linkorder %t | FileCheck %s
# CHECK: [Nr] Name {{.*}} Size ES Flg Lk Inf
# CHECK-NEXT: [ 0] {{.*}}
# CHECK-NEXT: [ 1] .linkorder {{.*}} 000004 00 AL 3 0
# CHECK-NEXT: [ 2] .ignore {{.*}}
# CHECK-NEXT: [ 3] .text {{.*}}
# CHECK: Hex dump of section '.linkorder':
# CHECK-NEXT: [[#%x,ADDR:]] 01020003
[ELF][test] Add another -triple=x86_64 to linkorder-mixed.s Fixes an error on macOS: error: mach-o section specifier uses an unknown section type
2020-08-06 08:00:16 +08:00
# RUN: llvm-mc --filetype=obj -triple=x86_64 --defsym EXTRA=1 %s -o %t.o
[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
2020-08-15 01:23:45 +08:00
# RUN: ld.lld %t.o -o %t1
# RUN: llvm-readelf -S -x .linkorder %t1 | FileCheck %s --check-prefix=CHECK1
# CHECK1: [Nr] Name {{.*}} Size ES Flg Lk Inf
# CHECK1-NEXT: [ 0] {{.*}}
# CHECK1-NEXT: [ 1] .linkorder {{.*}} 000005 00 AL 2 0
# CHECK1-NEXT: [ 2] .text {{.*}}
# CHECK1: Hex dump of section '.linkorder':
# CHECK1-NEXT: [[#%x,ADDR:]] 01020004 03
[ELF] Allow SHF_LINK_ORDER sections to have sh_link=0 Part of https://bugs.llvm.org/show_bug.cgi?id=41734 The semantics of SHF_LINK_ORDER have been extended to represent metadata sections associated with some other sections (usually text). The associated text section may be discarded (e.g. LTO) and we want the metadata section to have sh_link=0 (D72899, D76802). Normally the metadata section is only referenced by the associated text section. sh_link=0 means the associated text section is discarded, and the metadata section will be garbage collected. If there is another section (.gc_root) referencing the metadata section, the metadata section will be retained. It's the .gc_root consumer's job to validate the metadata sections. # This creates a SHF_LINK_ORDER .meta with sh_link=0 .section .meta,"awo",@progbits,0 1: .section .meta,"awo",@progbits,foo 2: .section .gc_root,"a",@progbits .quad 1b .quad 2b Reviewed By: pcc, jhenderson Differential Revision: https://reviews.llvm.org/D72904
2020-08-06 07:09:41 +08:00
.section .text,"ax",@progbits,unique,0
.Ltext0:
.section .text,"ax",@progbits,unique,1
.Ltext1:
.section .linkorder,"ao",@progbits,0,unique,0
.byte 0
.section .linkorder,"ao",@progbits,.Ltext0
.byte 1
.section .linkorder,"ao",@progbits,.Ltext1
.byte 2
.ifdef EXTRA
.section .linkorder,"a",@progbits
.byte 4
.else
.section .ignore,"ao",@progbits,.Ltext1
.endif
.section .linkorder,"ao",@progbits,0,unique,3
.byte 3