binfmt/elf_loadfile: Set sh_addr even if SHF_ALLOC == 0 #270
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Set sh_addr for regions that are not allocated. Some relocations might depend on this.
The fault in my case occurs when setting CONFIG_HAVE_CXX=y. In this case, the .ctor and .dtor sections do not get allocated, but the crt code depends on linker defined symbols _sctors/_ectors etc. These generate PC relative relocations and thus, the .ctor and .dtor output sections need an output VMA even though nothing is there. Otherwise the relocations will point to god knows where (in my case to address 0).
The problem results in full system crash later:
elf_symvalue: Other: 00000000+00000001=00000001
up_relocateadd: PCREL_HI20 at c00002dc [00000417] to sym=0x80409e80 st_value=1 _calc_imm: offset=-3221226203: hi=-786432 lo=-731
up_relocateadd: ERROR: PCREL_HI20 at c00002dc bad:ffffffff40000000 elf_relocateadd: ERROR: Section 2 reloc 52: Relocation failed: -22
The RISC-V elf64 linker does not like the uninitialized PC relative relocation entries, as the relocation offset cannot be reached with with the RV64 instruction set.
More about this issue can be found here:
apache#11322