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

[Ard Biesheuvel via Phabricator via llvm-commits]

ardb added a comment.

In D111181#3045770 <https://reviews.llvm.org/D111181#3045770>, @MaskRay wrote:

>> 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.

Where is this specified?

> 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.

The use case in question does not require the symtab section or strtab section, but I agree that this is an inconsistency.

> `--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.

We have a file like this

  [ 1] .text             PROGBITS         0000000000000000  00001000
       0000000000024379  0000000000000000 AXo       0     0     4096
  ...
  [ 4] .rodata           PROGBITS         0000000000000000  0002be80
       0000000000005f01  0000000000000000 AMS       0     0     64
  ...
  [ 9] .rela.text        RELA             0000000000000000  00031e00
       000000000000dc50  0000000000000018  AI      48     1     8
  ...
  [40] .rela.rodata[...] RELA             0000000000000000  00045a50
       0000000000000060  0000000000000018  AI      48     4     8
  ...
  [48] .symtab           SYMTAB           0000000000000000  00092208
       000000000000c558  0000000000000018          50   1252     8
  ...
  [50] .strtab           STRTAB           0000000000000000  0009ea62
       000000000000b44b  0000000000000000           0     0     1

Relocation section '.rela.init.rodata' at offset 0x48298 contains 131 entries:

  Offset          Info           Type           Sym. Value    Sym. Name + Addend

000000000000  06f200000105 R_AARCH64_PREL32  0000000000000000 .rela.text + 0
000000000008  06f300000105 R_AARCH64_PREL32  0000000000000000 .rela.rodata + 0
...

Symbol table '.symtab' contains 2105 entries:

   Num:    Value          Size Type    Bind   Vis      Ndx Name
  ...
  1778: 0000000000000000     0 SECTION GLOBAL DEFAULT    9 .rela.text
  1779: 0000000000000000     0 SECTION GLOBAL DEFAULT   40 .rela.rodata

The reason we want this is to be able to track how/where the text and rodata were modified after they were loaded into memory and relocated in-place.

Are you claiming that this arrangement violates the ELF spec? If it does, it would be helpful if you could point out why this is the case. I agree that this is an unusual use of ELF sections, but that by itself should not be a justification for disregarding this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111181