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/linkerscript/linkorder.s

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

84 lines
3.1 KiB
ArmAsm
Raw Normal View History

Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
## Contiguous SHF_LINK_ORDER sections.
[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: echo 'SECTIONS { .rodata : {BYTE(0) *(.rodata*) BYTE(4)} \
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# RUN: .text : {*(.text.bar) *(.text.foo)} }' > %t.lds
# RUN: ld.lld -T %t.lds %t.o -o %t
# RUN: llvm-readelf -S -x .rodata -x .text %t | FileCheck %s
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
[ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed Currently, `error: incompatible section flags for .rodata` is reported when we mix SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an output section. This is overconstrained. This patch allows mixed flags with the requirement that SHF_LINK_ORDER sections must be contiguous. Mixing flags is used by Linux aarch64 (https://github.com/ClangBuiltLinux/linux/issues/953) .init.data : { ... KEEP(*(__patchable_function_entries)) ... } When the integrated assembler is enabled, clang's -fpatchable-function-entry=N[,M] implementation sets the SHF_LINK_ORDER flag (D72215) to fix a number of garbage collection issues. Strictly speaking, the ELF specification does not require contiguous SHF_LINK_ORDER sections but for many current uses of SHF_LINK_ORDER like .ARM.exidx/__patchable_function_entries there has been a requirement for the sections to be contiguous on top of the requirements of the ELF specification. This patch also imposes one restriction: SHF_LINK_ORDER sections cannot be separated by a symbol assignment or a BYTE command. Not allowing BYTE is a natural extension that a non-SHF_LINK_ORDER cannot be a separator. Symbol assignments can delimiter the contents of SHF_LINK_ORDER sections. Allowing SHF_LINK_ORDER sections across symbol assignments (especially __start_/__stop_) can make things hard to explain. The restriction should not be a problem for practical use cases. Reviewed By: psmith Differential Revision: https://reviews.llvm.org/D77007
2020-03-29 14:12:04 +08:00
# CHECK: [ 1] .rodata {{.*}} AL 3
# CHECK: [ 3] .text {{.*}} AX 0
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK: Hex dump of section '.rodata':
[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
# CHECK-NEXT: 00030102 04
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK: Hex dump of section '.text':
# CHECK-NEXT: 0201
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
[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: echo 'SECTIONS { .rodata : {BYTE(0) *(.rodata*) BYTE(4)} \
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# RUN: .text : {*(.text.foo) *(.text.bar)} }' > %t1.lds
# RUN: ld.lld -T %t1.lds %t.o -o %t1
# RUN: llvm-readelf -S -x .rodata -x .text %t1 | FileCheck --check-prefix=CHECK1 %s
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
[ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed Currently, `error: incompatible section flags for .rodata` is reported when we mix SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an output section. This is overconstrained. This patch allows mixed flags with the requirement that SHF_LINK_ORDER sections must be contiguous. Mixing flags is used by Linux aarch64 (https://github.com/ClangBuiltLinux/linux/issues/953) .init.data : { ... KEEP(*(__patchable_function_entries)) ... } When the integrated assembler is enabled, clang's -fpatchable-function-entry=N[,M] implementation sets the SHF_LINK_ORDER flag (D72215) to fix a number of garbage collection issues. Strictly speaking, the ELF specification does not require contiguous SHF_LINK_ORDER sections but for many current uses of SHF_LINK_ORDER like .ARM.exidx/__patchable_function_entries there has been a requirement for the sections to be contiguous on top of the requirements of the ELF specification. This patch also imposes one restriction: SHF_LINK_ORDER sections cannot be separated by a symbol assignment or a BYTE command. Not allowing BYTE is a natural extension that a non-SHF_LINK_ORDER cannot be a separator. Symbol assignments can delimiter the contents of SHF_LINK_ORDER sections. Allowing SHF_LINK_ORDER sections across symbol assignments (especially __start_/__stop_) can make things hard to explain. The restriction should not be a problem for practical use cases. Reviewed By: psmith Differential Revision: https://reviews.llvm.org/D77007
2020-03-29 14:12:04 +08:00
# CHECK1: [ 1] .rodata {{.*}} AL 3
# CHECK1: [ 3] .text {{.*}} AX 0
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK1: Hex dump of section '.rodata':
[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
# CHECK1-NEXT: 00010302 04
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK1: Hex dump of section '.text':
# CHECK1-NEXT: 0102
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
## Adjacent input sections descriptions are contiguous.
[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
## Orphan section .text.bar precedes .text.foo. However, don't swap the order of .rodata.*
## because they are in different InputSectionDescriptions.
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# RUN: echo 'SECTIONS { .rodata : {*(.rodata.foo) *(.rodata.bar)} }' > %t2.lds
# RUN: ld.lld -T %t2.lds %t.o -o %t2
# RUN: llvm-readelf -S -x .rodata %t2 | FileCheck --check-prefix=CHECK2 %s
[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
# CHECK2: [ 1] .rodata {{.*}} AL 5
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK2: [ 4] .text.bar {{.*}} AX 0
[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
# CHECK2-NEXT: [ 5] .text.foo {{.*}} AX 0
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
# CHECK2: Hex dump of section '.rodata':
[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
# CHECK2-NEXT: 010302
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
## Non-contiguous SHF_LINK_ORDER sections, separated by a BYTE.
[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: echo 'SECTIONS { .rodata : {*(.rodata.foo) BYTE(0) *(.rodata.bar)} }' > %t3.lds
# RUN: ld.lld -T %t3.lds %t.o -o %t3
# RUN: llvm-readelf -S -x .rodata %t3 | FileCheck --check-prefix=CHECK3 %s
# CHECK3: [ 1] .rodata {{.*}} AL 5
# CHECK3: [ 4] .text.bar {{.*}} AX 0
# CHECK3: [ 5] .text.foo {{.*}} AX 0
# CHECK3: Hex dump of section '.rodata':
# CHECK3-NEXT: 01000302
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
## Non-contiguous SHF_LINK_ORDER sections, separated by a non-SHF_LINK_ORDER section.
[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: echo 'SECTIONS { .rodata : {*(.rodata.foo) *(.text) *(.rodata.bar)} }' > %t4.lds
# RUN: ld.lld -T %t4.lds %t.o -o %t4
# RUN: llvm-readelf -x .rodata %t4 | FileCheck --check-prefix=CHECK4 %s
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
[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
# CHECK4: Hex dump of section '.rodata':
# CHECK4-NEXT: 01cccccc 0302
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
[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
## Non-contiguous SHF_LINK_ORDER sections, separated by a symbol assignment.
# RUN: echo 'SECTIONS { .rodata : {*(.rodata.foo) a = .; *(.rodata.bar)} }' > %t5.lds
# RUN: ld.lld -T %t5.lds %t.o -o %t5
# RUN: llvm-readelf -S -x .rodata %t5 | FileCheck --check-prefix=CHECK2 %s
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
.global _start
_start:
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
.section .ro,"a"
.byte 0
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
.section .text.bar,"a",@progbits
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
.byte 2
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
.section .text.foo,"a",@progbits
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
.byte 1
Fix pr32816. When using linkerscripts we were trying to sort SHF_LINK_ORDER sections too early. Instead of always doing two runs of assignAddresses, record the section order in processCommands. llvm-svn: 301830
2017-05-02 04:32:39 +08:00
.section .rodata.foo,"ao",@progbits,.text.foo
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
.byte 1
[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
## If the two .rodata.bar sections are in the same InputSectionDescription,
## 03 (sh_link!=0) will be ordered before 02 (sh_link=0).
.section .rodata.bar,"a",@progbits
[ELF][test] Improve linkerscript/linkorder.s
2020-03-29 14:11:55 +08:00
.byte 2
[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
.section .rodata.bar,"ao",@progbits,.text.bar
.byte 3