[PATCH] D61584: [DebugInfo] Some fields do not need relocations even relax is enabled.

[Hsiangkai Wang via Phabricator via llvm-commits]

HsiangKai added a comment.

In D61584#1579871 <https://reviews.llvm.org/D61584#1579871>, @dblaikie wrote:

> In D61584#1579860 <https://reviews.llvm.org/D61584#1579860>, @HsiangKai wrote:
>
> > In D61584#1574203 <https://reviews.llvm.org/D61584#1574203>, @dblaikie wrote:
> >
> > > Does this solution extend/address other label deltas, like those that would appear in the other DWARF/non-frame sections? (eg: currently we use a length in the DWARF high_pc because it means not having to use a relocation for high_pc, which reduces object size - so, does this fix cause relocations to be used for that length expression to ensure they're correct if the linker changes the instructions in that range?)
> >
> >
> > After D45181 <https://reviews.llvm.org/D45181> committed, LLVM will generate relocation pairs for symbol difference expressions if target enables relaxation. So, it will generate relocations for high_pc due to it is a symbol difference expression of end symbol and start symbol of the function range. Such as,
> >
> >   .word   .Lfunc_begin0           # DW_AT_low_pc
> >   .word   .Lfunc_end4-.Lfunc_begin0 # DW_AT_high_pc
> >
> >
> > This commit modified the condition to generate relocations for symbol difference expressions. Not all symbol difference expressions are related to executable code. However, only executable code will be modified by linker for relaxation. So, we do not need to generate relocations for symbol differences not located in executable code sections.
>
>
> Good to know - so has LLVM been creating incorrect DWARF in these cases so far - or has no target enabled linker relaxation yet?
>
> Is there any way to make this more targeted - does linker relaxation allow arbitrary machine code changes? Or is there something more fine-grained - so we could compute compile-time constants for some label differences, but only use linker relocations for cases where we know the instruction sequence includes something relaxable?


AFAIK only RISC-V enables this feature. Currently, .debug_frame/.eh_frame is wrong after relaxation. I already fixed parts of the problem in D58335 <https://reviews.llvm.org/D58335>. In D58335 <https://reviews.llvm.org/D58335>, .debug_frame/.eh_frame will generate relocations if relaxation is enabled. Otherwise, it will not aware relaxation at all and it doesn't work to do frame inspection when debugging.

Linker relaxation processes some patterns of instruction sequences. For example, RISC-V could use auipc/jalr to jump to 32-bits pc-relative address. If linker knows the jump target is within +/-1 Mib, it could replace auipc/jalr to jal. The replacement will shorten the instruction sequence. So, the label differences between these instruction sequences may be changed after relaxation. That is why we need to annotate relocation types for these symbol differences in code sections.

Currently, there is no way to make it more targeted. When relaxation is enabled, it assumes all code sequences may be changed after relaxation. If we want to make placement of relocations more specific, we need to inspect every instruction between two symbols when we create symbol difference expressions for them. I think it will do a lot of work to gain few benefits. (Fewer relocations, smaller object code, less linker efforts, etc.)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61584/new/

https://reviews.llvm.org/D61584