[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)

[Fangrui Song via llvm-branch-commits]

MaskRay wrote:

> > I don't think this means that we unsupport -no-pie use cases
> 
> Yes, we'd still support -no-pie, but we'd fail to support -no-pie -mcmodel=medium.
>
> > cost of layout purity
> 
> I see that you feel strongly about this (e.g. by calling it "purity"), but I don't understand why. It's not the cost of the "if" in the implementation you're worried about, I think, but some other aspect?
> 
> > INSERT AFTER .lrodata would give different behaviors (a 32-bit offset relative to .text is positive in one while negative in the other)
> 
> I agree that the sign of the relative offset will change...but why is that concerning? The whole point of "INSERT AFTER" is to avoid specifying the entire layout. Does it matter that the offset relative to .text is sometimes negative and sometimes positive?
> 
> > which we should not treat hand-wavy.
> 
> Have scripts been broken by the _unconditional_ change from the offset being always-negative to the offset being always-positive? It seems unlikely to me that they would be, but am I missing something? If they don't, then that seems like having it be conditional is also fine.

"fail to support -no-pie -mcmodel=medium" is an overstatement.
We support `-fpie -mcmodel=medium -no-pie`, and support alleviating relocation overflow pressure for text's references to `.data` and `.bss`.
We just do not alleviate relocation overflow pressure for text's absolute address reference to `.bss` (`-fno-pic`) due to not placing `.lrodata` at the end.

I believe we have some disagreement on (a) how much convenience the linker should provide and (b) whether an uncommon use case should be made explicit (`INSERT [BEFORE|AFTER]`) instead of relying on a linker behavior (especially if the linker code would become ugly).

I think very rarely no-pie users actually care about the codegen difference (e.g. a PIC jump table needs extra instructions).
The motivation is primarily for avoiding dynamic relocations. Have you thought about using `-fpie -no-pie` (or `-fpic`) instead of `-fno-pic -no-pie`?
That would solve the #78521 problem.

When I made the large data layout change, I not only thought about impending needs of x86-64, but also other architectures which have or will get large code model.
ISTM aarch64/ppc64/riscv64 would all be fine with .lrodata at the beginning even in the -fno-pic mode.


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