Note: There is sometimes no need to generate rellocation via PLT.
Example - when symbol is not undefined and we are not creating shared library. Then we can create relative relocation instead of referencing and creating PLT records.
That is how ld behaves I believe.
Details
Diff Detail
Event Timeline
ELF/Target.cpp | ||
---|---|---|
314–316 | Your test does not seem to cover this code. (I just run your test without applying this code, and it didn't die with "unrecognized reloc" error defined below, so a relocation with R_x86_64_PLT32 did not reach this function.) |
ELF/Target.cpp | ||
---|---|---|
314–316 | Without applying this code this relocations are handled in another branch and consumed by: void InputSection<ELFT>::relocate( if (Target->relocNeedsPlt(Type, Body)) { <--- here SymVA = Out<ELFT>::Plt->getEntryAddr(Body); Type = Target->getPLTRefReloc(Type); } but since my case does not need plt then execution moves forward to relocateOne() and fails there without R_X86_64_PLT32 handler. |
ELF/Target.cpp | ||
---|---|---|
314–316 | Does not need PLT for _start I mean. |
LGTM with a nit.
Please update the test by adding a PLT32 relocation referring a symbol which is resolved within the same file, like this.
.global _start, foo _start: jmp bar@PLT jmp bar@PLT jmp zed@PLT jmp foo@PLT jmp _start@plt foo:
This looks to break self hosting for me. r250578 works fine, but this (r250584) leads to test fails during check-clang.
I think the bug is just that we produce unnecessary relocations:
callq atexit@PLT
atexit:
will create a dynamic relocation.
I will fix it early tomorrow.
Great, it works, thanks a lot ! That gives a chance for lazy relocations patch: http://reviews.llvm.org/D13856
Your test does not seem to cover this code. (I just run your test without applying this code, and it didn't die with "unrecognized reloc" error defined below, so a relocation with R_x86_64_PLT32 did not reach this function.)