Re: [PATCH] AArch64: Optimize ADD relocations that resolve to zero
Sivan Shani <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
From: Sivan Shani <[email protected]> I would like to ground and clarify the discussion with a concrete example: test.s ``` .text .global _start _start: add x0, x1, #:tprel_hi12:tlsvar add x2, x2, #:lo12:absvar ret .section .tdata,"awT",@progbits .align 3 tlsvar: .hword 0xf0f0 .data .balign 4096 absvar: .hword 0xf0f0 ``` 1. Default: final link The relocations are consumed, idempotency is irrelevant: ``` $AS -o test.o test.s $LD -o test.elf test.o $OBJDUMP -dr test.elf 400120: aa0103e0 mov x0, x1 400124: d503201f nop ``` 2. Relocatable link With '--relocatable', no relocations or optimizations are applied: ``` $LD --relocatable -o test.elf test.o $OBJDUMP -dr test.elf 0: 91400020 add x0, x1, #0x0, lsl #12 0: R_AARCH64_TLSLE_ADD_TPREL_HI12 tlsvar 4: 91000042 add x2, x2, #0x0 4: R_AARCH64_ADD_ABS_LO12_NC .data ``` idempotency is preserved/irrelevant 3. Final link with '--emit-relocs' ``` $LD --emit-relocs -o test.elf test.o $OBJDUMP -dr test.elf 400120: aa0103e0 mov x0, x1 400120: R_AARCH64_TLSLE_ADD_TPREL_HI12 tlsvar 400124: d503201f nop 400124: R_AARCH64_ADD_ABS_LO12_NC .data ``` This is the case that needs a policy decision. The relocation records are retained, but their target instructions are not. '--emit-relocs' retain relocation information mainly for post link analysis and optimization tools. Two possible interpretations: 1. Retained relocations must remain applicable to their target instructions. 2. Retained relocations principally describe the provenance of the linked code and are not necessarily safe to apply again after linker relaxation. The first interpretation requires disabling such optimization under '--emit-relocs', or rewriting/removing the retained relocation. The second interpretation permits the current behavior, but post link consumers must tolerate relocations whose original instruction class has changed. The retained information may still identify the affected address, symbol and original relocation expression, perhaps even sufficient to reconstruct some of the original instructions. There is existing precedent that linker processing is not universally idempotent. GOT and PLT generating relocations have allocation side effects, and some TLS relaxations rewrite instruction sequences while relocations are retained. It would be useful to establish whether this behavior is regarded as intentional precedent or something to change. LLD also performs relaxations with '--emit-relocs', although '--no-relax' can be used when preserving unrelaxed instruction/relocation pairs is required. We could consider giving this optimization the same policy control. Therefore, the question is specifically what guarantee '--emit-relocs' should provide: - relocations that remain applicable, or - relocation metadata that may describe code before linker optimization. If the latter is acceptable, retaining the current behavior may be reasonable. If the former is required, the optimization should be suppressed or the retained relocations adjusted.