This has turned out to be unnecessary, and while some ability to set VAStart
will be needed at some point, this is not clearly the right direction.
llvm-svn: 250205
What was done:
1) .got.plt section is created for functions that requires PLT. .got.plt has 3 predefined empty entries now that are required for dynamic linker.
Also other new items created are configured to have correct jump to PLT[N].
2) PLT section now has PLT[0] entry, also others ones are configured to support PLT->GOT(.got.plt) calls.
3) Implemented .rel[a].plt sections (based on patch http://reviews.llvm.org/D13569).
4) Fixed plt relocations types (based on patch http://reviews.llvm.org/D13589).
NOTES:
The .plt.got zero entry is still empty now. According to ELF specification it should hold the address of the dynamic structure, referenced with the symbol
_DYNAMIC. The _DYNAMIC entry points to the .dynamic section which contains information used by the ELF interpreter to setup the binary.
Differential Revision: http://reviews.llvm.org/D13651
llvm-svn: 250169
Now all Target<Arch> classes are used only in Target.cpp.
We can put them in an anonymous namespace. In order to avoid
merge conflict with other people's patches, I'll do that later.
llvm-svn: 250168
Under PPC64 ELF v1 ABI, the symbols associated with each function name don't
point directly to the code in the .text section (or similar), but rather to a
function descriptor structure in a special data section named .opd. The
elements in the .opd structure include a pointer to the actual code, and a the
relevant TOC base value. Both of these are themselves set by relocations.
When we have a local call, we need the relevant relocation to refer directly to
the target code, not to the function-descriptor in the .opd section. Only when
we have a .plt stub do we care about the address of the .opd function
descriptor itself.
So we make a few changes here:
1. Always write .opd first, so that its relocated data values are available
for later use when writing the text sections. Record a pointer to the .opd
structure, and its corresponding buffer.
2. When processing a relative branch relocation under ppc64, if the
destination points into the .opd section, read the code pointer out of the
function descriptor structure and use that instead.
This this, I can link, and run, a dynamically-compiled "hello world"
application on big-Endian PPC64/Linux (ELF v1 ABI) using lld.
llvm-svn: 250122
Under the PPC64 ELF ABI, functions that might call into other modules (and,
thus, need to load a different TOC base value into %r2), need to restore the
old value after the call. The old value is saved by the .plt code, and the
caller only needs to include a nop instruction after the call, which the linker
will transform into a TOC restore if necessary.
In order to do this the relocation handler needs two things:
1. It needs to know whether the call instruction it is modifying is targeting
a .plt stub that will load a new TOC base value (necessitating a restore after
the call).
2. It needs to know where the buffer ends, so that it does not accidentally
run off the end of the buffer when looking for the 'nop' instruction after the
call.
Given these two pieces of information, we can insert the restore instruction in
place of the following nop when necessary.
llvm-svn: 250110
This is mostly an adaptation of the code in LLVM's
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, and handles a sufficient
number of relocations to link a 'hello world' program on big-Endian PPC64/Linux
(ELF v1 ABI).
llvm-svn: 250101
The required page alignment is different on different targets. On PowerPC, for
example, we need 64K pages (the loader won't set different permissions on a
finer granularity than that). I've set the existing targets to what I believe
to be the correct values, and have updated the regression tests accordingly.
llvm-svn: 249760
The size of a .plt entry is different on different targets (it is,
specifically, much larger than 8 on all PPC ABIs). There is no functional
change here (later patches to create .plt entries for PPC64 will depend on this
change).
llvm-svn: 249756
Reapply r249726 (and r249723), hopefully with the correct test fixups this time.
Original commit message:
Address a FIXME in ELF/Writer.cpp: Make VAStart a target-dependent property.
I've set the values for the existing targets to what I believe to be the
correct values, and updated the regression tests accordingly.
llvm-svn: 249752
Address a FIXME in ELF/Writer.cpp: Make VAStart a target-dependent property.
I've set the values for the existing targets to what I believe to be the
correct values, and updated the regression tests accordingly.
llvm-svn: 249723
This was clearly wrong (thanks Rui for spotting), and I honestly would
like to get this tested so such mistakes won't repeat. Unfortunately, I
wasn't (easily) able to craft a test that exposes the bad behavior.
Ideally, we would like to get tests of this kind for all relocations, but
at the time of writing, this is not true. So, for now just fix this bug
and try to re-evaluate a way to test this in the future.
llvm-svn: 249359
Besides a trivial MIPS support the patch introduces new TargetInfo class
member getDefaultEntry() to override default name of the entry symbol.
MIPS uses __start for that.
Differential Revision: http://reviews.llvm.org/D13227
llvm-svn: 248779
Unfortunately the i386 and x86_64 relocation have the same numerical value
and it is a probably a bit much to add got support for another architecture
just to test this.
llvm-svn: 248326
This is just enough to get PLT working on 32 bit x86.
The idea behind using a virtual interface is that it should be easy to
convert any of the functions to template parameters if any turns out to be
performance critical.
llvm-svn: 248308
Hal Finkel