It seems that __cxa_demangle function on the buildbot tried to demangle
a variable "tlsvar" as a C++ symbol. Do not call that function unless
it does not start with "_Z" which is the prefix of mangled names.
llvm-svn: 257661
Fix: Added missed input file.
Initial commit message:
[ELF/AArch64] - Implemented R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 and R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC relocations
* R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 is calculated as Page(G(GTPREL(S+A))) – Page(P), set an ADRP immediate field to bits [32:12] of X; check –2^32 ≤ X < 2^32;
* R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC is calculated as G(GTPREL(S+A)), set an LD offset field to bits [11:3] of X. No overflow check; check that X&7 = 0.
Differential revision: http://reviews.llvm.org/D16117
llvm-svn: 257596
* R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 is calculated as Page(G(GTPREL(S+A))) – Page(P), set an ADRP immediate field to bits [32:12] of X; check –2^32 ≤ X < 2^32;
* R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC is calculated as G(GTPREL(S+A)), set an LD offset field to bits [11:3] of X. No overflow check; check that X&7 = 0.
Differential revision: http://reviews.llvm.org/D16117
llvm-svn: 257588
MIPS _gp_disp designates offset between start of function and gp pointer
into GOT therefore any relocations against it do not require dynamic
relocation.
llvm-svn: 257492
On Windows different versions of 'sed' work in different text/binary
mode by default. If default mode is text, sed produces corrupted binary
files. Unfortunately there is no standard command line option to select
the mode. Some 'sed' support '-b' to switch to binary mode, while other
ones support '--text' option and does not have '-b' option at all.
llvm-svn: 257471
On MIPS O32 ABI, _gp_disp is a magic symbol designates offset between
start of function and gp pointer into GOT. To make seal with such symbol
we add new method addIgnoredStrong(). It adds ignored symbol with global
binding to prevent the symbol substitution. The addIgnored call is not
enough here because this call adds a weak symbol which might be
substituted by symbol from shared library.
Differential Revision: http://reviews.llvm.org/D16084
llvm-svn: 257449
Summary: This is no longer needed now that the new ELF implementation supports AMDGPU.
Reviewers: ruiu, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15954
llvm-svn: 257390
R_AARCH64_TSTBR14 is calculated as S+A-P,
Set the immediate field of a TBZ/TBNZ instruction to bits [15:2] of X; check -2^15 ≤ X < 2^15
Differential revision: http://reviews.llvm.org/D15824
llvm-svn: 257334
R_AARCH64_CONDBR19 is calculated as S+A-P,
Set the immediate field of a conditional branch instruction to bits [20:2] of X; check -2^20 ≤ X< 2^20.
Afaik there is no document for AARCH64 instruction encoding from official for unknown reason, so
I used gold source code and next link as a reference for implementation: http://kitoslab-eng.blogspot.ru/2012/10/armv8-aarch64-instruction-encoding.html. From which is clear that immediate field of a conditional branch instruction is 5 bits off. That is proved by output which is is equal to gold/bfd now.
Differential revision: http://reviews.llvm.org/D15809
llvm-svn: 257333
* Added instructions to generate R_X86_64_32 relocations. Without that next part of code was uncovered by test, code worked without it:
bool X86_64TargetInfo::relocNeedsPlt(uint32_t Type, const SymbolBody &S) const {
if (needsCopyRel(Type, S))
return false;
* Removed -e main, added _start
Differential revision: http://reviews.llvm.org/D15714
llvm-svn: 257331
DLL export tables usually contain dllexport'ed symbol RVAs so that
applications which use the DLLs can find symbols from the DLLs.
However, there's a minor feature to "forward" DLL symbols to other
DLLs.
If you set an RVA to a string whose form is "<dllname>.<symbolname>"
(e.g. "KERNEL32.ExitProcess") instead of symbol RVA to the export
table, the loader interprets that as a forwarder symbol, and resolve
that symbol from the specified DLL.
This patch implements that feature.
llvm-svn: 257243
We used to have code in SymbolTable constructor to add entry symbols, etc.
That code has been moved to Driver. We can remove the constructor.
llvm-svn: 257214
For historical reasons, some add* functions for SymbolTable returns a
pointer to a SymbolBody, while some are not. This patch is to make them
consistently return a pointer to a newly added symbol.
llvm-svn: 257211
R_X86_64_PLT32 is handled in the same way as R_X86_64_PC32 by
relocateOne(), so this function does not seems to be needed.
Without this code, all tests still pass.
http://reviews.llvm.org/D15971
llvm-svn: 257203
All non-trivial relocation decisions need explanations like this
to help readers understand not only how relocations are handled but
why they are handled these ways. This is a start.
llvm-svn: 257119
It wasn't actually pointing to the function at the start of the text section, and so the offset in the binary differed when we passed the file through a second time.
The __eh_frame section uses implicit relocations and when reducing this test case from explicit to implicit, I got
the offset wrong. This makes sure it is correct.
llvm-svn: 257101
The __eh_frame section contains relocations which can always be implicitly generated.
This patch tracks whether sections have only implicitly relocations and skips emitting them to the object file if that is the case.
The test case here ensures that this is the case for __eh_frame sections.
Reviewed by Lang Hames.
http://reviews.llvm.org/D15594
llvm-svn: 257099
In this patch, all symbols are resolved normally and then wrap options
are applied. Renaming is implemented by mutating `Body` pointers of
Symbols. (As a result, Symtab.find(SymbolName)->getName() may return
a string that's different from SymbolName, but that is by design.
I designed the symbol and the symbol table to allow this kind of
operations.)
http://reviews.llvm.org/D15896
llvm-svn: 257075
Summary: This will allow us to remove the AMDGPU support from old ELF.
Reviewers: rafael, ruiu
Differential Revision: http://reviews.llvm.org/D15895
llvm-svn: 257023
String tables in unstripped executable files are fairly large in size.
For example, lld's executable file is about 34.4 MB in my environment,
and of which 3.5 MB is the string table. Efficiency of string table
construction matters.
Previously, the string table was built in an inefficient way. We used
StringTableBuilder to build that and enabled string tail merging,
although tail merging is not effective for the symbol table (you can
only make the string table 0.3% smaller for lld.) Tail merging is
computation intensive task and slow.
This patch eliminates string tail merging.
I changed the way of adding strings to the string table in this patch
too. Previously, strings were added using add() and the same strings
were then passed to getOffset() to get their offsets in the string table.
In this way, getOffset() needs to look up a hash table to get offsets
for given strings. This is a violation of "we look up the symbol table
(or a hash table) only once for each symbol" dogma of the new LLD's
design. Hash table lookup for long C++ mangled names is slow.
I eliminated that lookup in this patch.
In total, this patch improves link time of lld itself about 12%
(3.50 seconds -> 3.08 seconds.)
llvm-svn: 257017
In a UI such as XCode, it can group the headers for a library with that library.
This is done in the CMakeLists.txt for the library itself by setting the path(s)
as ADDITIONAL_HEADER_DIRS.
LLVM already does this for all of its libraries, so just adding this to lld to
make things easier. Should be NFC.
llvm-svn: 257002
In a UI such as XCode, LLVM source files are in 'libraries' while clang
files are in 'clang libraries'.
This change moves the lld source to 'lld libraries' to make code browsing easier.
It should be NFC as the build itself is still the same, just the structure in a
UI differs.
llvm-svn: 257001
MipsReginfoInputSection is basically just a container of Elf_Mips_Reginfo
struct. This patch makes that struct directly accessible from others.
llvm-svn: 256984
The fixup content we encode here should be the offset from the
fixup location back to the last nonlocal label. We were only encoding
the address of the fixup, and not taking in to account the base address
of the atom we are in.
Updated the test case here to have a text section which will come before
the data section where the relocation lives. .data being at offset 0 had
previously been hiding this bug.
llvm-svn: 256974
Unlike ObjectFile or ArchiveFile, SharedFile had two parse functions,
parseSoName() and parse(). parse must have been called after parseSoName,
but that requirement was not obvious from their names. (So it looked
like you could call parse() on a shared object file right away.)
This patch rename parseRest. It is now obvious that there's no single
parse function for the shared object file.
llvm-svn: 256898
Previously, we handle archive files with --whole-archive this way:
create instances of ArchiveFile, call getMembers to obtain memory
buffers of archive members, and create ObjectFiles for the members.
We didn't call anything except getMembers if --whole-archive was
specified.
I noticed that we didn't actually have to create ArchiveFile instaces
at all for that case. All we need is to get a list of memory buffers
for members, which can be done by a non-member function.
This patch removes getMembers member function from ArchiveFile.
Also removed unnecessary code for memory management.
llvm-svn: 256893
The final section order in relocatable files was just a side effect
of the atom sorter. This meant that sections like __data were before
__text because __data has RW permissions and __text RX and RW was less
than RX in our enum.
Final linked images had an actual section/segment sorter. There was no
reason for the difference, so simplify a bunch of code and just use the
same sorted for everything.
Reviewed by Lang Hames.
http://reviews.llvm.org/D15868
llvm-svn: 256786
The encoded value should be an offset from the fixup location, which
means that it should take in to account the fixup offset in its section.
We weren't subtracting the base address of the atom, which meant that when
we parsed the file again for a round trip, we had 2x the atom address in our
target address.
I've also improved comments for these to try and describe what is going on.
There's no test case right now, as the bug is only exhibited when __data is at
a non-zero address in a -r link. A commit will soon sort the sections differently
and move __data to after __text. Then these relocations in
test/mach-o/parse-data-relocs-x86_64.yaml will test for this bug.
llvm-svn: 256779
Test did not catch this either, so I`ll improve it and recommit later.
Original commit message:
[ELF] - Optimize .eh_frame section: remove CIE if all FDEs referencing it were removed.
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256693
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256638
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
The assembly at the top of this file contained more relocations than
the YAML. I regenerated it so that we'd have complete relocation testing.
Also added detailed explanations of the relocations in the file so that
future people don't have to try decode them when something goes wrong.
llvm-svn: 256064
@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
Rui Ueyama