[PATCH] D102296: [ELF] getRelocatedSection: remove the check for ET_REL object file

Wed May 26 00:32:53 PDT 2021

jhenderson added a comment.

In D102296#2780324 <https://reviews.llvm.org/D102296#2780324>, @dblaikie wrote:

> In D102296#2778940 <https://reviews.llvm.org/D102296#2778940>, @jhenderson wrote:
>
>> In D102296#2778439 <https://reviews.llvm.org/D102296#2778439>, @Amir wrote:
>>
>>> @jhenderson: thanks for the suggestion. I'm going to add the Object unit test for this change.
>>> The motivation is the use of relocations by BOLT for function reordering optimization (specifically, to find references to functions). We recommend that users keep relocations in the final binary: https://github.com/facebookincubator/BOLT#usage
>>
>> I think I follow now, thanks. Dynamic relocations should probably still be omitted by this lookup, i.e. `getRelocatedSection` only deals with static relocations. Not all dynamic relocation sections have an associated section, so this function will fail on them.
>>
>>> llvm-dwarfdump is relying on getRelocatedSection() to return section_end() for ELF files of types other than relocatable objects. We've changed the function to return relocatable section for other types of ELF files. As a result, llvm-dwarfdump started re-processing relocations for sections that already had relocations applied, e.g. in executable files, and this resulted in wrong values reported.
>>
>> It seems to me that for Elf_Rel relocations, you can't really reapply them, because the addend has been overwritten by the final patched value. So, as I understand it, the only way you can reliably know how to reapply relocations is with Elf_Rela relocations. I think this means you need to change llvm-dwarfdump too, to only reapply relocations for ET_REL objects? (It's harmless to do so for other ET_* kinds, iff the relocation types are Elf_Rela of course, but it's pointless work).
>
> Presumably we don't want to reapply them, right? (unless BOLT is modifying the relocations and expecting them to be reapplied) I'm assuming there's some property we should be able to observe that indicates the relocations have already been applied so we should ignore them?

I don't know BOLT at all, but if functions within an executable were to be reordered, the relocations referencing that function would need reapplying so that calls to it are targeting the right address. The resultant values would be different, because the target address would be different.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102296