2016-09-21 23:56:44 +08:00
|
|
|
# REQUIRES: x86
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %tfile1.o
|
|
|
|
|
2020-11-13 00:46:53 +08:00
|
|
|
# RUN: echo "SECTIONS { .abc : { *(SORT(.foo.*) .a* .a* SORT(.bar.*) .b*) } }" > %t1.script
|
2016-09-21 23:56:44 +08:00
|
|
|
# RUN: ld.lld -o %t1 --script %t1.script %tfile1.o
|
2020-11-13 00:46:53 +08:00
|
|
|
# RUN: llvm-readelf -x .abc %t1 | FileCheck %s
|
2016-09-21 23:56:44 +08:00
|
|
|
|
[ELF] Sort by input order within an input section description
According to
https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics
for `*(.a .b)`, the order should match the input order:
* for `ld 1.o 2.o`, sections from 1.o precede sections from 2.o
* within a file, `.a` and `.b` appear in the section header table order
This patch implements the behavior. The interaction with `SORT*` and --sort-section is:
Matched sections are ordered by radix sort with the keys being `(SORT*, --sort-section, input order)`,
where `SORT*` (if present) is most significant.
> Note, multiple `SORT*` within an input section description has undocumented and
> confusing behaviors in GNU ld:
> https://sourceware.org/pipermail/binutils/2020-November/114083.html
> Therefore multiple `SORT*` is not the focus for this patch but
> this patch still strives to have an explainable behavior.
As an example, we partition `SORT(a.*) b.* c.* SORT(d.*)`, into
`SORT(a.*) | b.* c.* | SORT(d.*)` and perform sorting within groups. Sections
matched by patterns between two `SORT*` are sorted by input order. If
--sort-alignment is given, they are sorted by --sort-alignment, breaking tie by
input order.
This patch also allows a section to be matched by multiple patterns, previously
duplicated sections could occupy more space in the output and had erroneous zero bytes.
The patch is in preparation for support for
`*(SORT_BY_INIT_PRIORITY(.init_array.* .ctors.*)) *(.init_array .ctors)`,
which will allow LLD to mix .ctors*/.init_array* like GNU ld (gold's --ctors-in-init-array)
PR44698 and PR48096
Reviewed By: grimar, psmith
Differential Revision: https://reviews.llvm.org/D91127
2020-11-13 00:53:11 +08:00
|
|
|
## Sections matched by patterns between two SORT are sorted separately by input order.
|
|
|
|
## Note, GNU ld has a strange behavior with more than one SORT* https://sourceware.org/pipermail/binutils/2020-November/114083.html
|
|
|
|
## In the absence of SORT, our multi-pattern behavior matches GNU ld.
|
2020-11-13 00:46:53 +08:00
|
|
|
# CHECK: Hex dump of section '.abc'
|
[ELF] Sort by input order within an input section description
According to
https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics
for `*(.a .b)`, the order should match the input order:
* for `ld 1.o 2.o`, sections from 1.o precede sections from 2.o
* within a file, `.a` and `.b` appear in the section header table order
This patch implements the behavior. The interaction with `SORT*` and --sort-section is:
Matched sections are ordered by radix sort with the keys being `(SORT*, --sort-section, input order)`,
where `SORT*` (if present) is most significant.
> Note, multiple `SORT*` within an input section description has undocumented and
> confusing behaviors in GNU ld:
> https://sourceware.org/pipermail/binutils/2020-November/114083.html
> Therefore multiple `SORT*` is not the focus for this patch but
> this patch still strives to have an explainable behavior.
As an example, we partition `SORT(a.*) b.* c.* SORT(d.*)`, into
`SORT(a.*) | b.* c.* | SORT(d.*)` and perform sorting within groups. Sections
matched by patterns between two `SORT*` are sorted by input order. If
--sort-alignment is given, they are sorted by --sort-alignment, breaking tie by
input order.
This patch also allows a section to be matched by multiple patterns, previously
duplicated sections could occupy more space in the output and had erroneous zero bytes.
The patch is in preparation for support for
`*(SORT_BY_INIT_PRIORITY(.init_array.* .ctors.*)) *(.init_array .ctors)`,
which will allow LLD to mix .ctors*/.init_array* like GNU ld (gold's --ctors-in-init-array)
PR44698 and PR48096
Reviewed By: grimar, psmith
Differential Revision: https://reviews.llvm.org/D91127
2020-11-13 00:53:11 +08:00
|
|
|
# CHECK-NEXT: 0x00000000 01020306 05040708 090b0c0a
|
2016-09-21 23:56:44 +08:00
|
|
|
|
|
|
|
# RUN: echo "SECTIONS { \
|
2020-11-13 00:46:53 +08:00
|
|
|
# RUN: .abc : { *(SORT(.foo.* EXCLUDE_FILE (*file1.o) .bar.*) .a* SORT(.bar.*) .b*) } \
|
2016-09-21 23:56:44 +08:00
|
|
|
# RUN: }" > %t2.script
|
|
|
|
# RUN: ld.lld -o %t2 --script %t2.script %tfile1.o
|
2020-11-13 00:46:53 +08:00
|
|
|
# RUN: llvm-readelf -x .abc %t2 | FileCheck %s
|
2016-09-21 23:56:44 +08:00
|
|
|
|
[ELF] Sort by input order within an input section description
According to
https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics
for `*(.a .b)`, the order should match the input order:
* for `ld 1.o 2.o`, sections from 1.o precede sections from 2.o
* within a file, `.a` and `.b` appear in the section header table order
This patch implements the behavior. The interaction with `SORT*` and --sort-section is:
Matched sections are ordered by radix sort with the keys being `(SORT*, --sort-section, input order)`,
where `SORT*` (if present) is most significant.
> Note, multiple `SORT*` within an input section description has undocumented and
> confusing behaviors in GNU ld:
> https://sourceware.org/pipermail/binutils/2020-November/114083.html
> Therefore multiple `SORT*` is not the focus for this patch but
> this patch still strives to have an explainable behavior.
As an example, we partition `SORT(a.*) b.* c.* SORT(d.*)`, into
`SORT(a.*) | b.* c.* | SORT(d.*)` and perform sorting within groups. Sections
matched by patterns between two `SORT*` are sorted by input order. If
--sort-alignment is given, they are sorted by --sort-alignment, breaking tie by
input order.
This patch also allows a section to be matched by multiple patterns, previously
duplicated sections could occupy more space in the output and had erroneous zero bytes.
The patch is in preparation for support for
`*(SORT_BY_INIT_PRIORITY(.init_array.* .ctors.*)) *(.init_array .ctors)`,
which will allow LLD to mix .ctors*/.init_array* like GNU ld (gold's --ctors-in-init-array)
PR44698 and PR48096
Reviewed By: grimar, psmith
Differential Revision: https://reviews.llvm.org/D91127
2020-11-13 00:53:11 +08:00
|
|
|
## Non-SORT patterns are sorted by --sort-section, breaking tie by input order.
|
|
|
|
# RUN: ld.lld -o %t4 --script %t1.script --sort-section=name %tfile1.o
|
|
|
|
# RUN: llvm-readelf -x .abc %t4 | FileCheck %s --check-prefix=CHECK2
|
|
|
|
|
|
|
|
# CHECK2: Hex dump of section '.abc'
|
|
|
|
# CHECK2-NEXT: 0x00000000 01020304 05060708 090a0b0c
|
|
|
|
|
2016-09-21 23:56:44 +08:00
|
|
|
.text
|
|
|
|
.globl _start
|
|
|
|
_start:
|
|
|
|
|
2020-11-13 00:46:53 +08:00
|
|
|
.section .foo.2,"a"; .byte 2
|
|
|
|
.section .foo.3,"a"; .byte 3
|
|
|
|
.section .foo.1,"a"; .byte 1
|
2016-09-21 23:56:44 +08:00
|
|
|
|
2020-11-13 00:46:53 +08:00
|
|
|
.section .a6,"a"; .byte 6
|
|
|
|
.section .a5,"a"; .byte 5
|
|
|
|
.section .a4,"a"; .byte 4
|
2016-09-21 23:56:44 +08:00
|
|
|
|
2020-11-13 00:46:53 +08:00
|
|
|
.section .bar.7,"a"; .byte 7
|
|
|
|
.section .bar.9,"a"; .byte 9
|
|
|
|
.section .bar.8,"a"; .byte 8
|
2016-09-21 23:56:44 +08:00
|
|
|
|
2020-11-13 00:46:53 +08:00
|
|
|
.section .b11,"a"; .byte 11
|
|
|
|
.section .b12,"a"; .byte 12
|
|
|
|
.section .b10,"a"; .byte 10
|