Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@293283 91177308-0d34-0410-b5e6-96231b3b80d8
Mapping symbols allow a mapping symbol aware disassembler to
correctly disassemble the PLT when the code immediately prior to the
PLT is Thumb.
To implement this we add a function to add symbols with local
binding to be defined in SyntheticSymbols.
Differential Revision: https://reviews.llvm.org/D28956
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@293044 91177308-0d34-0410-b5e6-96231b3b80d8
A necessary first step towards range extension thunks is to delay
the creation of thunks until the layout of InputSections within
OutputSections has been done.
The change scans the relocations directly from InputSections rather
than looking in the ELF File the InputSection came from. This will
allow a future change to redirect the relocations to symbols defined
by Thunks rather than indirect when resolving relocations.
A side-effect of moving ThunkCreation is that the OutSecOff of
InputSections may change in an OutputSection that contains Thunks.
In well behaved programs thunks are not in OutputSections with
dynamic relocations.
Differential Revision: https://reviews.llvm.org/D28811
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@292359 91177308-0d34-0410-b5e6-96231b3b80d8
Addded quotes to be consistent with x64 messages,
where quotes were used for nicer reporting 'Unknown' relocations initially.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291752 91177308-0d34-0410-b5e6-96231b3b80d8
We had an error when met this relocation
after latest changes aboult listing
x86 relocations explicitly.
Since we support R_X86_64_NONE,
and GNU ld supports R_386_NONE,
it seems reasonable to have.
Differential revision: https://reviews.llvm.org/D28552
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291672 91177308-0d34-0410-b5e6-96231b3b80d8
Previously some value was returned by default for relocations by getRelExpr(),
even if relocation actually was not supported.
This is orthogonal alternative to D28094.
Instead of implementing probably useless R_386_PC8/R_386_8 relocations,
this patch uses them in a testcase to demonstrate what happens
when LLD mets unsupported relocations.
Patch passes all testcases and changes logic only for x86.
Differential revision: https://reviews.llvm.org/D28516
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@291658 91177308-0d34-0410-b5e6-96231b3b80d8
In a shared library an undefined symbol is implicitly imported. If the
symbol is called as a function a PLT entry is generated for it. When the
caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT
entries are in ARM state.
This change allows undefined symbols to have thunks in the same way that
shared symbols may have thunks.
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290951 91177308-0d34-0410-b5e6-96231b3b80d8
This is last known noticable fatal() in target.cpp.
We also have other ones for unknown relocations or
creating unknown targets, but that one can be just error I think.
Used yaml2obj to generate test.
Differential revision: https://reviews.llvm.org/D28049
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290335 91177308-0d34-0410-b5e6-96231b3b80d8
We probably would want to avoid fatal() if we can in context of librarification,
but for me reason of that patch is to help D27900 go.
D27900 changes errors reporting to something like
error: text1
note: text2
note: text3
where hint used to provide additional information about location. In that case
I can't just call fatal() because user will not see notes after that what adds additional complication to handle.
So It is good to switch fatal() to error() where it is possible.
Also it adds testcase with broken relocation number.
Previously we did not have any, It checks that error() instead of fatal() works fine.
Differential revision: https://reviews.llvm.org/D27973
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290239 91177308-0d34-0410-b5e6-96231b3b80d8
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@290062 91177308-0d34-0410-b5e6-96231b3b80d8
When compiling -fpie and linking with the --pie option the R_ARM_GOTBREL
relocation to D is resolved by writing the value of D into the .got slot
and emitting an R_ARM_RELATIVE relocation for it.
This changes adds the R_ARM_RELATIVE relocation to the switch in
relocateOne() so we can process the GotSection relocation to write the
value of the variable as well as emitting the dynamic relocation.
Differential revision: https://reviews.llvm.org/D27678
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289527 91177308-0d34-0410-b5e6-96231b3b80d8
The i386 glibc ld.so expects the .got.slot entry that is relocated by a
R_386_IRELATIVE relocation to point directly at the ifunc resolver and
not the address of the PLT entry + 6 (thus entering the lazy resolver).
This is also the case for ARM and I suspect it is because these use REL
relocations and can't use the addend field to store the address of the
ifunc resolver. If the lazy resolver is used we get an error message
stating that only R_386_JUMP_SLOT is supported.
As ARM and i386 share the same code, I've removed the ARM specific test
and added a writeIgotPlt() function that by default calls writeGotPlt().
ARM and i386 override this to write the address of the ifunc resolver.
Differential Revision: https://reviews.llvm.org/D27581
git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@289198 91177308-0d34-0410-b5e6-96231b3b80d8
Jack Andersen
Peter Smith
Rui Ueyama
George Rimar
Peter Collingbourne
Rafael Espindola