Differences from ld and lld when handling orphan sections in the presence of MEMORY

[jonathonpenix]

Description
eld seems to place orphan sections according to the MEMORY region attributes, but it seems that ld and lld have special cases around this where they may ignore the region attributes. See https://reviews.llvm.org/D112925 for some discussion around this in lld. See also https://maskray.me/blog/2024-06-02-understanding-orphan-sections. I'm not sure the original motivation for this behavior in ld.

I'm not sure if eld wants to mirror this behavior or just document it as a divergence from lld/ld, etc.

This came up when testing Zephyr where some tests would fail due to the placement of orphaned .eh_frame sections (the test below isn't exactly matching that situation, but is derived from that). The .eh_frames have since been explicitly /DISCARD/'ed, but not sure if this will come up again.

Example

cat > main.c << '!'
const int data = 1;

int main(int argc, char *argv[]) {
  return 0;
}
!
cat > script.t << '!'
MEMORY {
  REGION1 (rx) : ORIGIN = 0x1000, LENGTH = 0x500
  REGION2 (!rwx) : ORIGIN = 0x2000, LENGTH = 0x500
}

SECTIONS {
  .text : { *(.text) } > REGION2
  /* Uncommenting below, lld places .rodata in REGION1, which makes sense to me.
   * Older versions of GNU ld still places .rodata in REGION2, which seems strange, but
   * it looks like this might have been fixed (newer version seem to place in REGION1)
   */
  /* .rodata : { *(.rodata) } */
}
!

clang --target=riscv32-unknown-elf -c main.c
ld.eld -march riscv32 -T script.t main.o -o eld.a.out
ld.lld -T script.t main.o -o lld.a.out
riscv32-unknown-elf-ld.bfd -T script.t main.o -o ld.a.out

Output

$ llvm-readelf -S eld.a.out
...
  [ 1] .text             PROGBITS        00002000 001000 000020 00  AX  0   0  2
  [ 2] .rodata           PROGBITS        00001000 002000 000004 00   A  0   0  4
...
$ llvm-readelf -S lld.a.out
...
  [ 1] .text             PROGBITS        00002000 001000 000020 00  AX  0   0  2
  [ 2] .rodata           PROGBITS        00002020 001020 000004 00   A  0   0  4
...
$ llvm-readelf -S ld.a.out
...
  [ 1] .text             PROGBITS        00002000 001000 000020 00  AX  0   0  2
  [ 2] .rodata           PROGBITS        00002020 001020 000004 00   A  0   0  4
...

[quic-seaswara]

Thanks for raising this issue and the pointer to the code reviews.

It is weird that uncommenting .rodata gets placed in .region1 and not commenting it will place in region2.

I feel this is an user error.

https://sourceware.org/binutils/docs-2.42/ld/MEMORY.html does not specify these rules, and I did read the discussion, I am not sure what cases to explicitly consider ...

Would Zephyr consider fixing the linker script to being consistent ? May be Zephyr does not expect eh_frame sections et all ?

If so adding a rule to the Zephyr images with DISCARD might be a way to fix it.

[jonathonpenix]

Responding to this out-of-order:

Would Zephyr consider fixing the linker script to being consistent ? May be Zephyr does not expect eh_frame sections et all ?

If so adding a rule to the Zephyr images with DISCARD might be a way to fix it.

Yeah, this is has been done in upstream Zephyr so there shouldn't be issues with it there anymore--I just mentioned that as context for where it came up originally.

It is weird that uncommenting .rodata gets placed in .region1 and not commenting it will place in region2.

I'm also not entirely sure on this, but my understanding it is that it is only orphan sections that get these special "rules" (so uncommenting makes it not an orphan anymore, so it goes into REGION1 as expected). I think the GNU ld behavior noted in the comment in the example was maybe a bug that was fixed? I can maybe try to track that down to see if there's more context.

I feel this is an user error.

https://sourceware.org/binutils/docs-2.42/ld/MEMORY.html does not specify these rules, and I did read the discussion, I am not sure what cases to explicitly consider ...

I think I agree here--at least, relying on this seems fairly error prone, but maybe there's some context I'm missing/misunderstanding.

Is there a place that we can document divergences in behavior from ld and lld? If so, it might be good just to document this and leave the eld behavior as-is for now until there's a compelling reason to change it.

[jonathonpenix]

Discussed this offline with Shankar and it sounds like we might just document the difference and close this for now. Updated flags accordingly, but will leave this open for now until we document.