The linker has to create __tls_get_addr, end and _end symbols.
Previously, these symbols were created in createSections().
But they are not actually related to creating output sections.
This patch moves code out of the function.
llvm-svn: 256441
Previously, this code was directly written in createSections()
function. This patch moves some code out of that function to a
new class.
llvm-svn: 256438
The number of output sections is usually limited, so the cost
of allocating them is not a bottleneck. This patch simplifies
the code by removing the allocators.
llvm-svn: 256437
OutputSectionBase already has virtual member functions.
This patch makes addSection() a virtual function to remove code
from Writer::createSections().
llvm-svn: 256436
The R_MIPS_GPREL16 / R_MIPS_GPREL32 relocations use the following
expressions for calculations:
```
local symbol: S + A + GP0 - GP
global symbol: S + A - GP
GP - Represents the final gp value, i.e. _gp symbol
GP0 - Represents the gp value used to create the relocatable object
```
The GP0 value is taken from the .reginfo data section defined by an object
file. To implement that I keep a reference to `MipsReginfoInputSection`
in the `ObjectFile` class. This reference is used by the
`ObjectFile::getMipsGp0` method to return the GP0 value.
Differential Revision: http://reviews.llvm.org/D15760
llvm-svn: 256416
The file crtbeginT.o has relocations pointing to the start of an empty
.eh_frame that is known to be the first in the link. It does that to
identify the start of the output .eh_frame. Handle this special case.
Differential revision: http://reviews.llvm.org/D15610
llvm-svn: 256414
This function was longer than 250 lines, which is way too long
in my own standard. This patch reduces the size. It is still
too long, but this patch should be toward the right direction.
llvm-svn: 256411
There are 3 symbol types that a .bc can provide during lto: defined,
undefined, common.
Defined and undefined symbols have already been refactored. I was
working on common and noticed that absolute symbols would become an
oddity: They would be the only symbol type present in a .o but not in
a.bc.
Looking a bit more, other than the special section number they were only
used for special rules for computing values. In that way they are
similar to TLS, and we don't have a DefinedTLS.
This patch deletes it. With it we have a reasonable rule of the thumb
for having a symbol kind: It exists if it has special resolution
semantics.
llvm-svn: 256383
In FreeBSD, rtld expects .ctors containing -1 (0xffffffff), and a
.ctors section containing the correct bits is provided to the linker as
input (/usr/lib/crtbegin.o).
Contents of section .ctors:
0000 ffffffff ffffffff ........
This section is not stripped even if not referenced or empty, also in
gold or ld.bfd. It would be nice to strip it when not needed but
since existing object files rely on that we can't do better to keep it
around.
Differential Revision: http://reviews.llvm.org/D15767
llvm-svn: 256373
Before this patch sections that go after relro sequence were placed at
the same memory page with relro ones. It caused segmentation fault on
freebsd.
Fixes PR25790.
Patch by George Rimar with some tweaks by myself.
llvm-svn: 256334
I am working on adding LTO support to the new ELF lld.
In order to do that, it will be necessary to represent defined and
undefined symbols that are not from ELF files. One way to do it is to
change the symbol hierarchy to look like
Defined : SymbolBody
Undefined : SymbolBody
DefinedElf<ELFT> : Defined
UndefinedElf<ELFT> : Undefined
Another option would be to use bogus Elf_Sym, but I think that is
getting a bit too hackish.
This patch does the Undefined/UndefinedElf. Split. The next one
will do the Defined/DefinedElf split.
llvm-svn: 256289
The patch adds support for R_MIPS_PC16, R_MIPS_PC19_S2, R_MIPS_PC21_S2,
R_MIPS_PC26_S2, R_MIPS_PCHI16, R_MIPS_PCLO16 relocations handling.
llvm-svn: 256172
This patch changes sequence of applying relocations, moving tls optimized relocation handling code before code for other locals.
Without that change relocation @GOTTPOFF against local symbol caused runtime error ("unrecognized reloc ...").
That change also should fix other tls optimized relocations, but I did not check them, that's a field for another patch.
R_X86_64_GOTTPOFF relocations against locals can be found when linking against libc.a(malloc.o):
000000000036 000600000016 R_X86_64_GOTTPOFF 0000000000000000 libc_tsd_MALLOC - 4
000000000131 000600000016 R_X86_64_GOTTPOFF 0000000000000000 libc_tsd_MALLOC - 4
Differential revision: http://reviews.llvm.org/D15581
llvm-svn: 256145
This relocation is similar to R_*_RELATIVE except that the value used in this relocation is the program address returned by the function, which takes no arguments, at the address of
the result of the corresponding R_*_RELATIVE relocation as specified in the processor-specific ABI. The purpose of this relocation to avoid name lookup for locally defined STT_GNU_IFUNC symbols at load-time.
More info can be found in ifunc.txt from https://sites.google.com/site/x32abi/documents.
Differential revision: http://reviews.llvm.org/D15235
llvm-svn: 256144
R_386_GOTOFF is calculated as S + A - GOT, where:
S - Represents the value of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
GOT - Represents the address of the global offset table.
Differential revision: http://reviews.llvm.org/D15383
llvm-svn: 256143
MIPS .reginfo section provides information on the registers used by
the code in the object file. Linker should collect this information and
write .reginfo section in the output file. This section contains a union
of used registers masks taken from input .reginfo sections and final
value of the `_gp` symbol.
For details see the "Register Information" section in Chapter 4 in the
following document:
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
The patch implements .reginfo sections handling with a couple missed
features: a) it does not put output .reginfo section into the separate
REGINFO segment; b) it does not merge `ri_cprmask` masks from input
section. These features will be implemented later.
Differential Revision: http://reviews.llvm.org/D15669
llvm-svn: 256119
The patch configure ELF header flags for MIPS target. For now the flags
are hard coded. In fact they depends on ELF flags of input object files
and selected emulation.
Differential Revision: http://reviews.llvm.org/D15575
llvm-svn: 256089
@indntpoff is similar to @gotntpoff, but for use in position dependent code. While @gotntpoff resolves to GOT slot address relative to the
start of the GOT in the movl or addl instructions, @indntpoff resolves to the
absolute GOT slot address. ("ELF Handling For Thread-Local Storage", Ulrich Drepper).
Differential revision: http://reviews.llvm.org/D15494
llvm-svn: 255884
Previously, OffsetInBSS is -1 if it has no information about copy
relocation, 0 if it needs a copy relocation, and >0 if its offset
in BSS has been assigned. These flags were too subtle. This patch
adds a new flag, NeedsCopy, to carry information about whether
a shared symbol needs a copy relocation or not.
llvm-svn: 255865
The function was used only in Writer.cpp and did not depend on SymbolTable.
There is no reason to have that function in SymbolTable.cpp.
llvm-svn: 255850
addELFFile was called only from addFile, and what it did was actually
just adding a file to the symbol table. There seems to be no reason
to separate the two.
llvm-svn: 255839
The `_gp_disp` is a magic symbol designates offset between start of
function and gp pointer into GOT. Only `R_MIPS_HI16` and `R_MIPS_LO16`
relocations are permitted with `_gp_disp`. The patch adds the `_gp_disp`
as an ignored symbol and adjusts symbol value before call the `relocateOne`
for `R_MIPS_HI16/LO16` relocations.
Differential Revision: http://reviews.llvm.org/D15480
llvm-svn: 255768
[ELF] - refactor of code in RelocationSection<ELFT>::writeTo()
Just a little reformat of 'if' conditions, NFC.
Differential revision: http://reviews.llvm.org/D15453
Fix was:
* Renamed unsigned Rel; to unsigned Reloc;
llvm-svn: 255631
as it broke buildbot:
http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/17836/steps/build_Lld/logs/stdio
/Users/buildslave/as-bldslv9/lld-x86_64-darwin13/llvm.src/tools/lld/ELF/OutputSections.cpp:268:14: error: redefinition of 'Rel'
unsigned Rel; ^
/Users/buildslave/as-bldslv9/lld-x86_64-darwin13/llvm.src/tools/lld/ELF/OutputSections.cpp:241:34: note: previous definition is here
for (const DynamicReloc<ELFT> &Rel : Relocs) {
That compiles fine on my MSVS 2015 thought.
llvm-svn: 255628
The `R_MIPS_JALR` is a relocation generated by gcc and gas. This
relocation points to the `jalr` instruction which might be optimized and
converted to the `b` instruction under some conditions.
Now we just ignore this relocation and keep instructions unchanged.
llvm-svn: 255453
It is reasonable to specify an entry point for shared objects - for
example, for the FreeBSD rtld ld-elf.so.1.
Unlike GNU ld we leave the entry address as 0 if -shared is specified
without -e.
Differential Revision: http://reviews.llvm.org/D15454
llvm-svn: 255349
R_X86_64_SIZE64/R_X86_64_SIZE32 relocations were introduced in 0.98v of "System V Application Binary Interface x86-64" (http://www.x86-64.org/documentation/abi.pdf).
Calculation for them is Z + A, where:
Z - Represents the size of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
Differential revision: http://reviews.llvm.org/D15335
llvm-svn: 255332
List all sections removed by garbage collection. This option is only effective if garbage collection has been enabled via the `--gc-sections' option.
Differential revision: http://reviews.llvm.org/D15327
llvm-svn: 255235
If R_386_PLT32 relocation is applied against symbol that can not be preempted then it can be resolved statically.
Patch implements it for x86 target.
Differential revision: http://reviews.llvm.org/D15376
llvm-svn: 255233
Implement the TLS relocation optimization for 32-bit x86 that is described in
"ELF Handling For Thread-Local Storage" by Ulrich Drepper, chapter 5,
"IA-32 Linker Optimizations". Specifically, this patch implements these
optimizations: LD->LE, GD->IE, GD->LD, and IE->LE.
Differential revision: http://reviews.llvm.org/D15292
llvm-svn: 255103
All relocations, which cannot be handled by the dynamic linker,
cause a linking error "rebuild with -fPIC".
Differential revision: http://reviews.llvm.org/D15193
llvm-svn: 254840
"Ulrich Drepper, ELF Handling For Thread-Local Storage" (5.5 x86-x64 linker optimizations, http://www.akkadia.org/drepper/tls.pdf) shows how GD can be optimized to IE.
This patch implements the optimization.
Differential revision: http://reviews.llvm.org/D15000
llvm-svn: 254713
Main aim of the patch to introduce basic support for TLS access models for x86 target.
Models using @tlsgd, @tlsldm and @gotntpoff are implemented.
Differential revision: http://reviews.llvm.org/D15060
llvm-svn: 254500
Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined
addends. Such addend is calculated using addends of both paired relocations.
Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16`
relocation. ABI requires to compute such combined addend in case of REL
relocation record format only.
For details see p. 4-17 at
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
This patch implements lookup of the next paired relocation suing new
`InputSectionBase::findPairedRelocLocation` method. The primary
disadvantage of this approach is that we put MIPS specific logic into
the common code. The next disadvantage is that we lookup `R_MIPS_LO16`
for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16`
might be paired with the single `R_MIPS_LO16`. From the other side
this way allows us to keep `MipsTargetInfo` class stateless and implement
later relocation handling in parallel.
This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against
`_gp_disp` symbol. In that case the relocations use a special formula for
the calculation. That will be implemented later.
Differential Revision: http://reviews.llvm.org/D15112
llvm-svn: 254461
Combination of @tlsgd and @gottpoff at the same time leads to miss of R_X86_64_TPOFF64 dynamic relocation. Patch fixes that.
@tlsgd(%rip) - Allocate two contiguous entries in the GOT to hold a tls index
structure (for passing to tls get addr).
@gottpoff(%rip) - Allocate one GOT entry to hold a variable offset in initial TLS
block (relative to TLS block end, %fs:0).
The same situation can be observed for x86 (probably others too, not sure) with corresponding for that target relocations: @tlsgd, @gotntpoff.
Differential revision: http://reviews.llvm.org/D15105
llvm-svn: 254443
Fix was:
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
=>
uint32_t getLocalTlsIndexVA() { return Base::getVA() + LocalTlsIndexOff; }
Both works for my MSVS.
Original commit message:
[ELF] - Refactor of tls_index implementation for tls local dynamic model.
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254433
It failed buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/3782/steps/build/logs/stdio
Target.cpp
In file included from /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/Target.cpp:20:
/home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/ELF/OutputSections.h:136:42: error: use of undeclared identifier 'getVA'
uint32_t getLocalTlsIndexVA() { return getVA() + LocalTlsIndexOff; }
llvm-svn: 254432
Patch contains the next 2 changes:
1) static variable Out<ELFT>::LocalModuleTlsIndexOffset moved to Out<ELFT>::Got. At fact there is no meaning for it to be separated from GOT class because at each place of using it anyways needs to call GOT`s getVA(). Also it is impossible to have that offset and not have GOT.
2) addLocalModuleTlsIndex -> addLocalModelTlsIndex (word "Module" changed to "Model"). Not sure was it a mistype or not but I think that update is closer to Urlich terminology.
Differential revision: http://reviews.llvm.org/D15113
llvm-svn: 254428
Splitted writeTo to separate tls relocs handling stuff which is too long for one method now. NFC.
Differential revision: http://reviews.llvm.org/D15012
llvm-svn: 254309
If an argument of the INPUT directive is a regular path, linker should
lookup it in the current folder first.
The fix does not contain any test cases because I think it is not a good
idea to pollute a current folder (which in general might be arbitrary)
by test files.
Differential Revision: http://reviews.llvm.org/D15027
llvm-svn: 254178
ABI specifies the allowed range for these relocations as 2^(n-1) <= X < 2^n.
The patch fixes checks and introduces precise tests for these relocations.
Differential revision: http://reviews.llvm.org/D14957
llvm-svn: 254146
In case a sysroot prefix is configured, and the filename starts with
the '/' character, and the script being processed was located inside
the sysroot prefix, the file's name will be looked for in the sysroot
prefix. Otherwise, the linker falls to the common lookup scheme.
It is slightly modified version of the commit r254031. The problem of
the initial commit was in the `is_absolute` call. On Windows 'C:\' is
absolute path but we do not need to find it under sysroot. In this patch
linker looks up a path under sysroot only if the paths starts with '/'
character.
llvm-svn: 254135
Implements @tlsld (LD to LE) and @tlsgd (GD to LE) optimizations.
Patch does not implement the GD->IE case for @tlsgd.
Differential revision: http://reviews.llvm.org/D14870
llvm-svn: 254101
Patch implements lazy relocations for x86.
One of features of x86 is that executable files and shared object files have separate procedure linkage tables. So patch implements both cases.
Detailed information about instructions used can be found in http://docs.oracle.com/cd/E19620-01/805-3050/chapter6-1235/index.html (search: x86: Procedure Linkage Table).
Differential revision: http://reviews.llvm.org/D14955
llvm-svn: 254098
R_MIPS_CALL16 relocation provides the same result as R_MIPS_GOT16
relocation but does not need to check the result on overflow.
Differential Revision: http://reviews.llvm.org/D14916
llvm-svn: 254092
This patch implements next relocations:
R_386_TLS_LE - Negative offset relative to static TLS (GNU version).
R_386_TLS_LE_32 - Offset relative to static TLS block.
These ones are created when using next code sequences:
* @tpoff - The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
* @ntpoff Calculate the negative offset of the variable it is added to relative to the static TLS block.
The operator must be used to compute an immediate value. The linker will report
an error if the referenced variable is not defined or it is not code for the executable
itself. No GOT entry is created in this case.
Information was found in Ulrich Drepper, ELF Handling For Thread-Local Storage, http://www.akkadia.org/drepper/tls.pdf, (6.2, p76)
Differential revision: http://reviews.llvm.org/D14930
llvm-svn: 254090
https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-26/index.html says:
R_386_GOTPC
Resembles R_386_PC32, except that it uses the address of the global offset table in its calculation. The symbol referenced in this relocation normally is _GLOBAL_OFFSET_TABLE_, which also instructs the link-editor to create the global offset table.
Currently _GLOBAL_OFFSET_TABLE_ has value == zero. And we use GOT address to calculate the relocation. This patch does not changes that. It just removes the method which is used only for x86. So it is close to non functional change.
Differential revision: http://reviews.llvm.org/D14993
llvm-svn: 254088
In the previous patch (r254003), I made the linker emit PT_GNU_STACK
unconditionally. But sometimes you want to have a control over the
presence of the segment. With this patch, you can omit the segment
by passing -z execstack option.
llvm-svn: 254039
In case a sysroot prefix is configured, and the filename starts with the
'/' character, and the script being processed was located inside the
sysroot prefix, the file's name will be looked for in the sysroot
prefix. Otherwise, the linker falls to the common lookup scheme.
https://www.sourceware.org/binutils/docs-2.24/ld/File-Commands.html
Differential Revision: http://reviews.llvm.org/D14916
llvm-svn: 254031
Partial (-z relro) and full (-z relro, -z now) relro cases are implemented.
Partial relro:
The ELF sections are reordered so that the ELF internal data sections (.got, .dtors, etc.) precede the program's data sections (.data and .bss).
.got is readonly, .got.plt is still writeable.
Full relro:
Supports all the features of partial RELRO, .got.plt is also readonly.
Differential revision: http://reviews.llvm.org/D14218
llvm-svn: 253967
R_X86_64_GOTTPOFF is not always requires GOT entries. Some relocations can be converted to local ones.
Differential revision: http://reviews.llvm.org/D14713
llvm-svn: 253966
With these relocations, it is now possible to build a simple "hello world"
program for AArch64 Debian.
Differential revision: http://reviews.llvm.org/D14917
llvm-svn: 253957
With this patch, lld creates PT_GNU_STACK segments only when all input
files have .note.GNU-stack sections. This is in line with other linkers
with a minor difference (we don't care about .note.GNU-stack rwx bits as
you can always remove .note.GNU-stack sections instead of setting x bit.)
At least, NetBSD loader does not understand PT_GNU_STACK segments and
reject any executables that have the section. This patch makes lld
compatible with such operating systems.
llvm-svn: 253797
Rui Ueyama