[llvm-branch-commits] MC: Emit symbols for R_X86_64_PLT32 relocation pointing to symbols with non-zero values. (PR #138795)

[Peter Collingbourne via llvm-branch-commits]

pcc wrote:

Sorry, let me try again with the concrete problem that I was seeing and trying to solve.

With this .s file:
```
.section .text.a,"ax", at progbits
jmp foo

.section .text.b,"ax", at progbits
bar:
ret

.text
jmp bar
foo:
ret
```
and with an lld patched with #138366:
```
$ ra/bin/clang -c jmp2.s
$ ra/bin/ld.lld jmp2.o --branch-to-branch
ld.lld: warning: cannot find entry symbol _start; not setting start address
$ objdump -d

a.out:     file format elf64-x86-64


Disassembly of section .text:

0000000000201120 <foo-0x5>:
  201120:	e9 06 00 00 00       	jmp    20112b <bar>

0000000000201125 <foo>:
  201125:	c3                   	ret
  201126:	e9 05 00 00 00       	jmp    201130 <bar+0x5>

000000000020112b <bar>:
  20112b:	c3                   	ret
```
The instruction at 0x201126 is incorrect. This is because of the interpretation of `jmp foo`. Currently it is assembled as `jmp .text+5` i.e. PLT32 with symbol `.text` and addend 1. With the current implementation of branch-to-branch this is treated as a branch to `.text` that needs 1 added to the operand (similar to the relative vtable case). Consequently it finds the relocation for `jmp bar` at the beginning of the section, assumes that is the target and incorrectly rewrites it.

After #138795 we have:
```
$ objdump -d

a.out:     file format elf64-x86-64


Disassembly of section .text:

0000000000201120 <foo-0x5>:
  201120:	e9 06 00 00 00       	jmp    20112b <bar>

0000000000201125 <foo>:
  201125:	c3                   	ret
  201126:	e9 fa ff ff ff       	jmp    201125 <foo>

000000000020112b <bar>:
  20112b:	c3                   	ret
```
The alternative fix, which I think I'm now leaning towards, would be to change how the branch-to-branch optimization handles relocations to STT_SECTION symbols. A relocation pointing to the STT_SECTION for .text with addend 1 would be treated as a branch to `.text+5` and it would be invalid to assemble a relative vtable relocation that points to STT_SECTION. It would also be consistent with how we process relocations for string tail merging and ICF among other places, e.g. [here](https://github.com/llvm/llvm-project/blob/8602a655a8150753542b0237fcca16d9ee1cd981/lld/ELF/ICF.cpp#L304). The downside is that it adds another special case for STT_SECTION but I guess that's fine.

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