The option now just sets NOW bit in DT_FLAGS_1 but some loaders
seem to require also BIND_NOW bit to be set in DT_FLAGS. This is,
also, what ld.bfd and gold do.
Differential Revision: http://reviews.llvm.org/D13883
llvm-svn: 250799
The two names are similar enough that they might lead to confusion.
The output of readobj clarifies but I missed it when I originally
committed this. Found while linking FreeBSD userland with lld.
llvm-svn: 250739
The reason of collecting all undefines in vector is that during reading files we already need to have Symtab created. Or like was done in that patch - to put undefines from scripts somewhere to delay Symtab.addUndefinedOpt() call.
Differential Revision: http://reviews.llvm.org/D13870
llvm-svn: 250711
Instead of specifically creating .plt entries for weak undef symbols, mirror
the logic in r250584, and use canBePreempted to determine is a REL24 relocation
needs a .plt entry. This might cause relocateOne to be called for a weak undef
symbol, with a REL24 relocation, but ignore this as a special case (this will
cause SA == 0, which won't happen under any other circumstance).
llvm-svn: 250597
There is sometimes no need to generate relocation 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.
Differential Revision: http://reviews.llvm.org/D13835
llvm-svn: 250584
When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to
0, and we're creating a shared library, we need to make sure that it stays 0
(because code that conditionally calls the weak function tests for this).
Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation
targets, making the address of the undefined weak symbol equal to the base
address of the shared library (which is non-zero). In general, we should not be
creating RelativeReloc relocs for undef weak symbols.
llvm-svn: 250558
R_PPC64_TOC does not have an associated symbol, but does have a non-zero VA
that target-specific code must compute using some non-trivial rule. We
handled this as a special case in PPC64TargetInfo::relocateOne, where
we knew to write this special address, but that did not work when creating shared
libraries. The special TOC address needs to be the subject of a
R_PPC64_RELATIVE relocation, and so we also need to know how to encode this
special address in the addend of that relocation.
Thus, some target-specific logic is necessary when creating R_PPC64_RELATIVE as
well. To solve this problem, we teach getLocalRelTarget to handle R_PPC64_TOC
as a special case. This allows us to remove the special case in
PPC64TargetInfo::relocateOne (simplifying code there), and naturally allows the
existing logic to do the right thing when creating associated R_PPC64_RELATIVE
relocations for shared libraries.
llvm-svn: 250555
If a section name is valid as a C identifier (which is rare because of
the leading '.'), linkers are expected to define __start_<secname> and
__stop_<secname> symbols. They are at beginning and end of the section,
respectively. This is not requested by the ELF standard, but GNU ld and
gold provide this feature.
llvm-svn: 250432
Unfortunately, the check was not as dead as I had thought, and adjusting the
starting VA again exposed the problem. We end up trying to relocate the bl
(using a 24-bit relative offset) to a symbol address of zero, and in general,
that does not fit.
Thus, reverting for now, and adding a test case.
llvm-svn: 250423
After some additional post-commit (post-revert) discussion and research, this
reverts, in part, r250205, so the ABI-recommended starting address can be used
on PPC64 (as is done by other linkers).
Also, this addresses the FIXME in ELF/Writer.cpp by making VAStart a
target-dependent property.
llvm-svn: 250378
If an argument for --entry is a number, that's not a symbol name but
an absolute address. If that's the case, the address is directly set
to ELF header's e_entry.
llvm-svn: 250334
Previously, we used input section names as output section names.
That resulted that we created lots of sections for comdat
or -f{function,data}-section sections.
This patch reduces the number of sections by dropping suffix from
all section names which start with ".text.", ".rodata.", ".data."
or ".bss.". GNU linker does this using the internal linker script,
but for LLD I chose to do that directly.
Interestingly, this makes the linker faster. Time to link Clang
is this.
Before:
real 0m0.537s
user 0m0.433s
sys 0m0.104s
After:
real 0m0.390s
user 0m0.268s
sys 0m0.120s
It make sense because previously we created 57659 sections now only 27.
llvm-svn: 250315
- Make the `MipsTargetInfo` template class with `ELFType` argument. Use
the argument to select an appropriate relocation type and read/write
routines.
- Add template function `add32` to add-and-write relocation value in
both big and little endian cases. Keep the `add32le` to reduce code
changes.
Differential Revision: http://reviews.llvm.org/D13723
llvm-svn: 250297
The documentation says: "You may separate commands using semicolons",
so they seem to be optional.
Differential Revision: http://reviews.llvm.org/D13703
llvm-svn: 250223
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
BSD's DSO files have undefined symbol "__progname" which is defined
in crt1.o. On that system, both user programs and system shared
libraries depend on each other.
In general, we need to put symbols defined by user programs which are
referenced by shared libraries to user program's .dynsym.
http://reviews.llvm.org/D13637
llvm-svn: 250176
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
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
George Rimar