[PATCH] D111181: [llvm-objcopy][ELF] Don't assume RELA sections are dynamic if they carry the SHF_ALLOC flag

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 6 09:49:04 PDT 2021


MaskRay added a comment.

> While this occurs rarely for normal user programs, the Linux kernel uses partially linked ET_REL objects as its loadable module format, and there, we sometimes rely on SHF_ALLOC to indicate to the module loader that the static relocations (which the Linux kernel fixes up at module load time) need to be preserved in memory after loading of the module completes.
>
> So let's extend the existing heuristic with a check against the file type: for ET_REL type files, which are only partiallly linked and cannot carry dynamic relocations, we assume that the RELA sections are static. For ET_DYN/ET_EXEC type files, we stick to the old behavior, which is to use the SHF_ALLOC flag as a hint to decide whether relocation sections are static or dynamic.

If this is a Linux kernel requirement, can you link to the related discussion?
>From my experience dealing with ELF files, I don't think the Linux kernel usage is correct.

SHT_REL[A] SHF_ALLOC sections are dynamic relocation sections.
Since ET_REL files should not contain dynamic linking information, it doesn't make sense to use SHT_REL[A] SHF_ALLOC sections.
At the very least SHF_ALLOC `.rela.text` linking to non-SHF_ALLOC `.symtab` seems wrong.

`--strip-debug` erroring on unrelated `error: Link field value 3 in section .rela.text is not a symbol table` may be undesired, but we may have other means to address the issue if you provide enough context.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111181



More information about the llvm-commits mailing list