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

Wed Oct 6 14:23:00 PDT 2021

ardb added a comment.

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

> In D111181#3046373 <https://reviews.llvm.org/D111181#3046373>, @ardb wrote:
>
>> 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?
>
> This area is not specified in the generic ABI. This is a convention used as an (unspecified) protocol between the linker and the loader.

Which linker and which loader? Does llvm-objcopy only target ELF files created with LLD for use in user programs? And which libc/libdl implementations is it limited to?

Please try to understand that ELF may be used in different ways in different contexts, and unspecified protocols and conventions that only cover user executables and shared libraries may not work for complex bare metal programs such as the Linux kernel.

> I think the convention started when SunOS contributed dynamic linking to System V release 4 which was then inherited to all ELF operating systems.

ELF user space programs, right? What about other contexts where ELF is used?

>>> 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.
>
> This is the exact point I question the Linux kernel's use case.
> So I asked for a link about the usage.

There is some background here:
https://android-review.googlesource.com/c/kernel/common/+/1842462/3

>>> `--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.
>
> The ELF specification is loosely specified in some areas. Not violating the ELF spec doesn't mean we should add some code (complexity).
> We need to place house rules.

House rules are fine if you communicate them in some way. Dismissing something because it violates unspecified protocols or unspecified house rules seems arbitrary at the very least.

I understand that you may dislike the use of SHF_ALLOC SHT_RELA sections in this manner, but that does not make it wrong, even if it is in poor taste.

> I requested a link so that we can discover whether the Linux kernel usage is legitimate, because I suspect this is an instance of the XY Problem.
> The Linux kernel usage can probably be fixed instead of hacking llvm-objcopy.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111181