[lld] ELF: CFI jump table relaxation. (PR #147424)

[Peter Collingbourne via llvm-commits]

pcc wrote:

> There is no accompanying test, making its transformations unclear.

Apologies if the description wasn't enough. My intent was to write a test once we agree on the protocol between the compiler and the linker.

I'll try to illustrate my goal with some assembly:
```
.section .text.jumptable,"ax", at progbits
f1:
jmp f1.cfi
.balign 8, 0xcc

f2:
jmp f2.cfi
.balign 8, 0xcc

f3:
jmp f3.cfi
.balign 8, 0xcc

.section .text.f1,"ax", at progbits
f1:
ret

.section .text.f2,"ax", at progbits
f2:
.balign 16, 0x90
ret

.section .text.f3,"ax", at progbits
f3:
.balign 16, 0x90
ret
```
I want the linker to do this:
```
.section .text.jumptable,"ax", at progbits
; f1.cfi was small enough to fit
f1:
ret
.balign 8, 0xcc

; f2.cfi could not fit in the jump table
f2:
jmp f2.cfi
.balign 8, 0xcc

; f3.cfi was last jump table entry and replaces the final jmp
f3:
.balign 16, 0x90
ret

; f2 stays where it was
.section .text.f2,"ax", at progbits
f2:
.balign 16, 0x90
ret
```
> Relying on a "magic" section name to trigger transformations feels unreliable and imprecise. Introducing a new section type and relocation type might justify the feature.

Agreed. I used a magic section name for expediency so that I'd have something to share in this PR.

So do you think that both a new section type and a new relocation type are needed? I was thinking that either/or would be enough.

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