[lld] [ELF] Don't relax PLT32 for branches from small into large code on x86-64 (PR #216409)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> > alanzhao/plt32-no-relax implements range-extension thunks. Only PLT32-unreachable branches switch to thunks. (The implementation may cause a link time regression for the majority of links that don't need to relax the section addresses twice.)
> > This patch scans relocations and and pretends SHF_X86_64_LARGE relocations as IPLT instead of measuring the distance. Both SHF_X86_64_LARGE and IPLT are hacky ways to achieve what you want. I don't think we should proceed with this approach.
> 
> Thanks for taking a look. What would you consider upstreamable here?
> 
> General thunk support looks like a long road, since a register-free thunk implies GOT indirection and eventually multiple GOTs.

The IPLT entry is itself a GOT-indirect jump. This approach doesn't avoid needing a reachable GOT entry, either.

(Technically, a register-free thunk doesn't have to go through .got, but a relative relocation will be needed, which is not ideal.

```
jmp *0(%rip)
.quad target  # R_X86_64_RELATIVE
```
)

Note: there is explicit ordering among .tdata, .init_array, .data.rel.ro, and .got/.got.plt. If .got is too far away from .text, you can use a linker script to order .got before other sections.

>  Is there a narrower change you'd accept in the meantime?

Honestly, no. The medium/large code model for x86-64 is still unsettled. A mechanism that looks minimal now can foreclose the design we eventually want. I'm not comfortable committing to a particular narrow change while that's open, including a scoped-down version of this one. 

Realistically the set of projects hitting this today is small - essentially Meta, Google, and perhaps ByteDance - and all of you are far better placed than a typical contributor to carry a local patch while the design settles. Given that, I'd rather you all run experiments internally for now than have upstream commit to a mechanism ahead of the design.

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