The MIPS target requires specific dynamic section entries to be defined.
* DT_MIPS_RLD_VERSION and DT_MIPS_FLAGS store predefined values.
* DT_MIPS_BASE_ADDRESS holds base VA.
* DT_MIPS_LOCAL_GOTNO holds the number of local GOT entries.
* DT_MIPS_SYMTABNO holds the number of .dynsym entries.
* DT_MIPS_GOTSYM holds the index of the .dynsym entry
which corresponds to the first entry of the global part of GOT.
* DT_MIPS_RLD_MAP holds the address of the reserved space in the data segment.
* DT_MIPS_PLTGOT points to the .got.plt section if it exists.
* DT_PLTGOT holds the address of the GOT section.
See "Dynamic Section" in Chapter 5 in the following document for detailed
description: ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
Differential revision: http://reviews.llvm.org/D14450
llvm-svn: 252857
The MIPS ABI has requirements to sort the entries in the .dyn.sym section.
Symbols which are not in the GOT have to precede the symbols which are added to
the GOT. The latter must have the same order as the corresponding GOT entries.
Since these sorting requirements contradict those of the GNU hash section,
they cannot be used together.
Differential revision: http://reviews.llvm.org/D14281
llvm-svn: 252854
This adds support for:
* Uniquing CIEs
* Dropping FDEs that point to dropped sections
It drops 657 488 bytes from the .eh_frame of a Release+Asserts clang.
The link time impact is smallish. Linking clang with a Release+Asserts
lld goes from 0.488064805 seconds to 0.504763060 seconds (1.034 X slower).
llvm-svn: 252790
GNU as can give it type SHT_PROGBITS or SHT_X86_64_UNWIND depending on
teh construct.
MC gives it type SHT_X86_64_UNWIND.
The linker has to canonicalize to one or the other so that there is only
one .eh_frame in the end.
llvm-svn: 252757
leaq symbol@tlsld(%rip), %rdi
call __tls_get_addr@plt
symbol@tlsld (R_X86_64_TLSLD) instructs the linker to generate a tls_index entry (two GOT slots) in the GOT for the entire module (shared object or executable) with an offset of 0. The symbol for this GOT entry doesn't matter (as long as it's either local to the module or null), and gold doesn't put a symbol in the dynamic R_X86_64_DTPMOD64 relocation for the GOT entry.
All other platforms defined in http://www.akkadia.org/drepper/tls.pdf except for Itanium use a similar model where global and local dynamic GOT entries take up 2 contiguous GOT slots, so we can handle this in a unified manner if we don't care about Itanium.
While scanning relocations we need to identify local dynamic relocations and generate a single tls_index entry in the GOT for the module and store the address of it somewhere so we can later statically resolve the offset for R_X86_64_TLSLD relocations. We also need to generate a R_X86_64_DTPMOD64 relocation in the RelaDyn relocation section.
This implementation is a bit hacky. It side steps the issue of GotSection and RelocationSection only handling SymbolBody entries by relying on a specific relocation type. The alternative to this seemed to be completely rewriting how GotSection and RelocationSection work, or using a different hacky signaling method.
llvm-svn: 252682
This is cleaner than computing relocations as if we had done it.
While at it, keep a single Phdr variable instead of multiple fields of it.
llvm-svn: 252352
This patch implements R_MIPS_GOT16 relocation for global symbols in order to
generate some entries in GOT. Only reserved and global entries are supported
for now. For the detailed description about GOT in MIPS, see "Global Offset
Table" in Chapter 5 in the followin document:
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
In addition, the platform specific symbol "_gp" is added, see "Global Data
Symbols" in Chapter 6 in the aforementioned document.
Differential revision: http://reviews.llvm.org/D14211
llvm-svn: 252275
For x86-64 the initial executable TLS block is placed directly before the
thread specific data register so compilers can directly access it via
R_X86_64_TPOFF32. Generate the correct (negative) offset for this case.
llvm-svn: 252131
This does not support TPOFF32 relocations to local symbols as the address calculations are separate. Support for this will be a separate patch.
llvm-svn: 251998
This is a case where there is inconsistency among ELF linkers:
* The spec says nothing special about empty sections.
* BFD ld removes them.
* Gold handles them like regular sections.
We were outputting them but sometimes ignoring them. This would create
odd looking outputs where a rw section could be in a ro segment for example.
The bfd way of doing things is also strange for the case where a symbol
points to the empty section.
Now we match gold and what seems to be the intention of the spec.
llvm-svn: 251988
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
Denis Protivensky