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 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
