It is required to fill up the GNU hash table section before its
finalize() method is called.
Differential Revision: http://reviews.llvm.org/D14196
llvm-svn: 251789
MachODefinedCustomSectionAtom.
The section names for these atoms are initialized from temporaries (e.g.
segName + "/" + sectName), so we can't use StringRef here.
llvm-svn: 251610
It is the GNU hash table section that should be reaponsible for storing its own
data and applying its requirements for the order to dynamic symbols.
Differential Revision: http://reviews.llvm.org/D14084
llvm-svn: 251502
GNU linkers accept both variants and at least for MIPS target gcc passes
joined variant of the '-m' option.
Differential Revision: http://reviews.llvm.org/D14133
llvm-svn: 251497
This matches ld.bfd and ld.gold behavior. The change is simple enough
and avoid trouble to consumers (they don't have to change their Makefiles).
Side note: found while trying to build FreeBSD base system with lld.
llvm-svn: 251408
There was a threading issue in the ICF code for COFF. That seems like
a venign bug in the sense that it doesn't produce an incorrect output,
but it oftentimes misses reducible sections. As a result, mergeable
sections could remain in outputs, which makes the output nondeterministic.
Basically the algorithm we are using for ICF is this: We group sections
so that identical sections will eventually be in the same group. Initially,
all sections are in one group. We split the group by relocation targets
until we get a convergence (if relocation targets are in different gruops,
the sections are different). Once a group is split, they will never be
merged.
Each section has a group ID. That variable itself is atomic, so there's
no threading issue at the level that we can use thread sanitizer.
The point is, when we split a group, we re-assign new group IDs to group
of sections. That are multiple separate writes to atomic varaibles.
Thus, splitting a group is not an atomic operation, and there's a small
chance that the other thread observes inconsistent group IDs.
Over-splitting is always "safe", so it will never create incorrect output.
I suspect that the nondeterminism stems from that point. However, I
cannot prove or fix that at this moment, so I'm going to avoid using
threads here.
llvm-svn: 251300
getFileOff functions defined for other classes return an offset
from beginning of the file. StringTableSection's getFileOff however
returned an offset from beginning of the section. That was confusing.
llvm-svn: 251192
This patch is an attempt to simplify assignAddresses function by splitting
it and using less variables. I tried to split the code to create PHDRs from
the code to assign addresses, but it didn't make this code simpler, so I
didn't do that in this patch.
llvm-svn: 251152
relocateOne is a function to apply a relocation. Previously, that
function took a pointer to Elf_Rel or Elf_Rela in addition to other
information that can be derived from the relocation entry. This patch
simplifies the parameter list. The new parameters, P or SA, are used
in the ELF spec to describe each relocation. These names make
relocateOne look like a mechanical, direct translation of the ELF spec.
llvm-svn: 251090
.eh_frame sections need to be preserved if they refer to live sections.
So the liveness relation is reverse for eh_frame sections. For now,
we simply preserve all .eh_frame sections. Thanks Rafael for pointing
this out. .jcr are kept for the same reason.
llvm-svn: 251068
Section garbage collection is a feature to remove unused sections
from outputs. Unused sections are sections that cannot be reachable
from known GC-root symbols or sections. Naturally the feature is
implemented as a mark-sweep garbage collector.
In this patch, I added Live bit to InputSectionBase. If and only
if Live bit is on, the section will be written to the output.
Starting from GC-root symbols or sections, a new function, markLive(),
visits all reachable sections and sets their Live bits. Writer then
ignores sections whose Live bit is off, so that such sections are
excluded from the output.
This change has small negative impact on performance if you use
the feature because making sections means more work. The time to
link Clang changes from 0.356s to 0.386s, or +8%.
It reduces Clang size from 57,764,984 bytes to 55,296,600 bytes.
That is 4.3% reduction.
http://reviews.llvm.org/D13950
llvm-svn: 251043
This patch implements --hash-style command line switch.
* By default, or with "sysv" or "both" parameters, the linker generates
a standard ELF hash section.
* With "gnu" or "both", it produces a GNU-style hash section.
That section requires the symbols in the dynamic symbol table section, which
are referenced in the GNU hash section, to be placed after not hashed ones and
to be sorted to correspond the order of hash buckets in the GNU Hash section.
The division function, as well as estimations for the section's parameters,
are just the first rough attempt and the subjects for further adjustments.
Differential Revision: http://reviews.llvm.org/D13815
llvm-svn: 251000
These classes are partially written, so almost all features
are FIXMEs. We do not want to add new FIXMEs to the classes
when we add new features to other non-stub classes.
llvm-svn: 250947
* 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
Rafael Espindola