* Move the responsibility to call SymbolBody::setDynamicSymbolTableIndex()
from the hash table to the dynamic symbol table.
* Hash table is not longer responsible for filling the dynamic symbol table.
* The final order of symbols of both symbol tables is set before writing
phase starts.
* Remove repeaded scan of the symbol table during writting SymbolTableSection.
Differential Revision: http://reviews.llvm.org/D13911
llvm-svn: 250864
The section header table index of the entry that is associated with the section name string table.
Differential Revision: http://reviews.llvm.org/D13904
llvm-svn: 250836
Target has supportsLazyRelocations() method which can switch lazy relocations on/off (currently all targets are OFF except x64 which is ON). So no any other targets are affected now.
Differential Revision: http://reviews.llvm.org/D13856?id=37726
llvm-svn: 250808
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
Given the name, it is natural for this function to compute the full target.
This will simplify SHF_MERGE handling by allowing getLocalRelTarget to
centralize the addend logic.
llvm-svn: 250731
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
If one file is MIPS64EL, all files are MIPS64EL, and vice versa.
We do not have to look up MIPS-ness for each file. Currently we
do not support 64-bit MIPS, so the config value is always false.
llvm-svn: 250566
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
When I initially implemented PPC64TargetInfo::isRelRelative, I included a fixed
set of relative relocations, and made the default false. In retrospect, this
seems unwise in two respects: First, most PPC64 relocations are relative
(either to the base address, the TOC, etc.). Second, most relocation targets
are not appropriate for R_PPC64_RELATIVE (which writes a 64-bit absolute
address). Thus, back off, and include only those relocations for which we test
(or soon will), and are obviously appropriate for R_PPC64_RELATIVE.
llvm-svn: 250540
