The content of reserved entries of the .got.plt section is target specific.
In particular, on x86_64 the zero entry holds the address of the .dynamic section,
but on AArch64 the same info is stored in the zero entry of the .got section.
Differential revision: http://reviews.llvm.org/D14703
llvm-svn: 253239
PT_GNU_STACK is a entry in the elf file format which contains the access rights (read, write, execute) of the stack,
it is always generated now. By default stack is not executable in this implementation.
-z execstack can be used to make executable.
Differential revision: http://reviews.llvm.org/D14571
llvm-svn: 253145
This sections can be protected with relro after resolving relocations by dynamic linker.
Differential revision: http://reviews.llvm.org/D14567
llvm-svn: 253018
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
Rui Ueyama