[lld] [ELF] Orphan placement: remove hasInputSections condition (PR #93761)

Fangrui Song via llvm-commits llvm-commits at lists.llvm.org
Thu May 30 11:37:32 PDT 2024


================
@@ -20,14 +20,14 @@
 
 # CHECK: Section Headers
 # CHECK: .pad
+# CHECK-NEXT: .orphan1
 # CHECK-NEXT: .text
 # CHECK-NEXT: .orphan2
 # CHECK-NEXT: .ro
-# CHECK-NEXT: .orphan1
 
 # CHECK: Segment Sections
-# CHECK-NEXT: .pad .text .orphan2
-# CHECK-NEXT: .ro .orphan1
+# CHECK-NEXT: .pad .orphan1 .text .orphan2
+# CHECK-NEXT: .ro
----------------
MaskRay wrote:

w/o this patch; .orphan1 is after .ro (the second A, but the first A that contains input sections).
```
  [ 1] .pad              PROGBITS        0000000000000000 001000 000008 00   A  0   0  1
  [ 2] .text             PROGBITS        0000000000000008 001008 000001 00  AX  0   0  4
  [ 3] .orphan2          PROGBITS        0000000000000009 001009 000001 00  AX  0   0  1
  [ 4] .ro               PROGBITS        000000000000000a 00100a 000001 00   A  0   0  1
  [ 5] .orphan1          PROGBITS        000000000000000b 00100b 000001 00   A  0   0  1
```

w/ this patch; .orphan1 is after .ro (the first A).
```
  [ 1] .pad              PROGBITS        0000000000000000 001000 000008 00   A  0   0  1
  [ 2] .orphan1          PROGBITS        0000000000000008 001008 000001 00   A  0   0  1
  [ 3] .text             PROGBITS        000000000000000c 00100c 000001 00  AX  0   0  4
  [ 4] .orphan2          PROGBITS        000000000000000d 00100d 000001 00  AX  0   0  1
  [ 5] .ro               PROGBITS        000000000000000e 00100e 000001 00   A  0   0  1
```

I think the new behavior is more reasonable.

> The key thing from our point of view is that the behaviour in this test, orphan-live-only.s is maintained.

orphan-live-only.s might be overly reduced. Is there a better justification for the skip-padding-section behavior?

Currently output sections without an input section rely heavily on the flags propagation rule.
With the introduction of `osec (READONLY) : { }` and possible future addition for SHF_EXECINSTR, I think these sections should be used as an anchor as well.

For the reasonable use cases, `WA pad WA pad WA`, w/o or w/o this patch, a new WA section will be placed at the end of the consecutive WA/pad sequence.
The same applies to `A pad A pad A`.

Therefore, I don't think a new RankFlag is needed.


https://github.com/llvm/llvm-project/pull/93761


More information about the llvm-commits mailing list