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
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 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
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
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
negDelta32 is only ever implicitly generated as the FDE->CIE reference.
We therefore don't emit a relocation for it in the object file in -r mode.
The value we write in to the FDE location therefore needs to point to the
final target address of the CIE, and not the inAtomAddress as it was currently
doing.
llvm-svn: 255835
We had some DEBUG prints these passes, but add more so that its clear where we are dumping
things, and what state we are in when we do so.
I'll be adding more and more DEBUG printing to try make it easier to observe whats going on
without having to attach a debugger.
llvm-svn: 255805
The delta64 relocation is represented as the pair ARM64_RELOC_SUBTRACTOR and ARM64_RELOC_UNSIGNED.
Those should always have the same offset, so this adds a check and tests to ensure this is the case.
Also updated the error printing in this case to shows both relocs when erroring on pair.
llvm-svn: 255274
table.
The first entry in the MachO symbol table is always the empty string: make sure
we reserve space for it, or we will overflow the symbol table by one byte.
No test case - this manifests as an occasional memory error. In the near future
I hope to set up a bot building and runnnig LLD with sanitizers - that should
catch future instances of this issue.
llvm-svn: 255178
The gcc_except_tab was generating these references to point to the typeinfo in the data section.
gcc_except_tab also had the DW_EH_PE_indirect flag set which means that at runtime we are going
to dereference this entry as if it is in the GOT.
Reviewed by Nick Kledzik in http://reviews.llvm.org/D15360.
llvm-svn: 255085
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
This is a basic initial implementation of the -flat_namespace and
-undefined options for LLD-darwin. It ignores several subtlties,
but the result is close enough that we can now link LLVM (but not
clang) on Darwin and pass all regression tests.
llvm-svn: 248732
This is a basic implementation that allows lld to emit binaries
consumable by the HSA runtime.
Differential Revision: http://reviews.llvm.org/D11267
llvm-svn: 246155
Add PT_PHDR segment depending on its availability in linker script's
PHDRS command, fallback if no linker script is given.
Handle FILEHDR, PHDRS and FLAGS attributes of program header.
Differential Revision: http://reviews.llvm.org/D11589
llvm-svn: 244743
Put sections to segments according to linker scripts if available.
Rework the code of TargetLayout::assignSectionsToSegments so it operates
on the given list of segments, which can be either read from linker scripts
or constructed as before.
Handle NONE segments defined in linker scripts by putting corresponding sections
to PT_NULL segment.
Consider flags set for segments through linker scripts.
Differential Revision: http://reviews.llvm.org/D10918
llvm-svn: 243002
This patch fixes the TLS dynamic variable exportation from .got.plt segments,
created by General-dynamic relocations (TLSDESC). Current code only export
symbols in dynamic table from .got sections.
llvm-svn: 242142
When using a linker script expression to change the address of a section, even
if the new address is more than a page of distance from the old address, lld
may put everything in the same segment, forcing it to be unnecessarily large.
This patch changes the logic in Segment::assignVirtualAddress() and
Segment::assignFileOffsets() to allow the segment to be sliced into two or more
if it detects a linker script expression that changes a section address.
Differential Revision: http://reviews.llvm.org/D10952
llvm-svn: 242096
When calculating the start address and size of a segment, lld mistakenly
attributed the start address of the last segment slice to the whole segment
when it should consider the start address of the first slice. In this case, in a
multi-slice segment, Segment::assignVirtualAddress() will return a wrong
segment start address to TargetLayout::assignVirtualAddress(). The effect of
this miscalculation is to allocate some program headers in unnecessarily far
away addresses. This commit fixes this.
Differential Revision: http://reviews.llvm.org/D10951
llvm-svn: 242089
The function uses parallel_for() and then writes error messages from the
parallel loop's body. This produces nondetermistic error messages. Instead,
copy error messages to a vector and sort it by the atom's file offsets before
printing all error messages after the parallel_for(). This results in a few
string copies, but only in the error case. (And passing tests seem more
important than performance.)
This makes tests elf/AArch64/rel-prel16-overflow.test and
elf/AArch64/rel-prel32-overflow.test pass on Windows: Both tests check that
atom error messages are emitted in a certain order, and on Windows they
happened to be emitted in a different order before this patch.
llvm-svn: 241988
This patch reimplements ELFLinkingContext::getDefaultInterpreter for aarch64
with correct loader name. It is required to exclude the loader from DT_NEEDED
in shared library creation.
llvm-svn: 241371
This patch reimplements ELFLinkingContext::getDefaultInterpreter for aarch64
with correct loader name. It is required to exclude the loader from DT_NEEDED
in shared library creation.
llvm-svn: 241370
This is GNU ELF linker extension used particularly by LibC code.
If input object files contain section named XXX, and the XXX is a valid C
identifier, and there are undefined or weak symbols __start_XXX/__stop_XXX,
linker should define __start_XXX/__stop_XXX symbols point to the begin/end
of the XXX section correspondingly.
For example, without support of this extension statically linked executables
for X86_64 and Mips (maybe other) targets do not flush IO buffers at the end
of executing.
llvm-svn: 241341
This patch adds initial general-dynamic TLS support for AArch64. Currently
no optimization is done to realx for more performance-wise models (initial-exec
or local-exec). This patch also only currently handles correctly executable
generation, although priliminary DSO support through PLT specific creation
is also added.
With this change clang/llvm bootstrap with lld is possible in static configuration
(some DSO creation fails due missing Linker script support, not AArch64 specific),
although make check also shows some issues.
llvm-svn: 241192
Some compilers may not add the section symbol in '.symtab' for the
.init_array and 'ldd' just ignore it. It results in global constructor
not being called in final executable.
This patch add both '.init_array' and '.fini_array' to be added in
Atom graph generation even when the section contains no symbol. An
already existing testcase is modified to check for such scenario.
The issue fixes the llvm test-suite regressions for both Single
and MultiSource files.
llvm-svn: 240570
The ObjectFileYAML.roundTrip serializes a default-constructed
NormalizedFile to YAML, triggering uninitialized memory reads.
While there use in-class member initializers.
llvm-svn: 240446
None of the implementations replace the SimpleFile with some other file,
they just modify the SimpleFile in-place, so a direct reference to the
file is sufficient.
llvm-svn: 240167
Common symbols will be handled in a separate patch because it seems
Hexagon redefines the notion of common symbol, which I'm not (yet)
very familiar with.
llvm-svn: 239951
Current approach for initial-exec in ELF/x86_64 is to create a GOT entry
and change the relocation to R_X86_64_PC32 to be handled as a GOT offfset.
However there are two issues with this approach: 1. the R_X86_64_PC32 is
not really required since the GOT relocation will be handle dynamically and
2. the TLS symbols are not being exported externally and then correct
realocation are not being applied.
This patch fixes the R_X86_64_GOTTPOFF handling by just emitting a
R_X86_64_TPOFF64 dynamically one; it also sets R_X86_64_TPOFF64 to be
handled by runtime one. For second part, the patches uses a similar
strategy used for aarch64, by reimplementing buildDynamicSymbolTable
from X86_64ExecutableWriter and adding the TLS symbols in the dynamic
symbol table.
Some tests had to be adjusted due the now missing R_X86_64_PC32 relocation.
With this test the simple testcase:
* t1.c:
__thread int t0;
__thread int t1;
__thread int t2;
__thread int t3;
* t0.c:
extern __thread int t0;
extern __thread int t1;
extern __thread int t2;
extern __thread int t3;
__thread int t4;
__thread int t5;
__thread int t6;
__thread int t7;
int main ()
{
t0 = 1;
t1 = 2;
t2 = 3;
t3 = 4;
t4 = 5;
t5 = 6;
t6 = 7;
t7 = 8;
printf ("%i %i %i %i\n", t0, t1, t2, t3);
printf ("%i %i %i %i\n", t4, t5, t6, t7);
return 0;
}
Shows correct output for x86_64.
llvm-svn: 239908
This patch fixes the wrong .tbss segment size generated for cases where
multiple modules have non initialized threads variables. For instance:
* t0.c
__thread int x0;
__thread int x1;
__thread int x2;
extern __thread int e0;
extern __thread int e1;
extern __thread int e2;
extern __thread int e3;
int foo0 ()
{
return x0;
}
int main ()
{
return x0;
}
* t1.c
__thread int e0;
__thread int e1;
__thread int e2;
__thread int e3;
lld is generating (for aarch64):
[14] .tbss NOBITS 0000000000401000 00001000
0000000000000010 0000000000000000 WAT 0 0 4
Where is just taking in consideration the largest tbss segment, not all
from all objects. ld generates a correct output:
[17] .tbss NOBITS 0000000000410dec 00000dec
000000000000001c 0000000000000000 WAT 0 0 4
This issue is at 'lib/ReaderWriter/ELF/SegmentChunks.cpp' where
Segment<ELFT>::assignVirtualAddress is setting wrong slice values, not taking care
of although tbss segments file size does noy play role in other segment virtual
address placement, its size should still be considered.
llvm-svn: 239906
Add method to query segments for specified output section name.
Return error if the section is assigned to unknown segment.
Check matching of sections to segments during layout on the subject of correctness.
NOTE: no actual functionality of using custom segments is implemented.
Differential Revision: http://reviews.llvm.org/D10359
llvm-svn: 239719
As noted on Errc.h:
// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.
And on some libstdc++ those virtual functions conclude that
------------------------
int main() {
std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;
}
-------------------------
should exit with 0.
llvm-svn: 239685
This patch fixes the TLS initial executable for AArch64. Current
implementation have two issues: 1. does not generate dynamic
R_AARCH64_TLS_TPREL64 relocation for the external module symbols,
and 2. does not export the TLS initial executable symbol in dynamic
symbol table.
The fix follows the MIPS strategy to add a arch-specific GOTSection
class to keep track of TLS symbols required to be place in dynamic
symbol table. It also overrides the buildDynamicSymbolTable for
ExecutableWrite class to add the symbols.
It also adds some refactoring on AArch64RelocationPass.cpp based on ARM
backend.
llvm-svn: 238981
This patch fixes the TLS local relocations alignment done by @238258.
As pointed out, the TLS size should not be considered, but rather the
TCB size based on maximum output segment alignment. Although it has
not shown in the TLS simple cases for test-suite, more comprehensible
tests with more local TLS variable showed wrong relocations values
being generated.
The local TLS testcase is expanded to add more tls variable (both
exported and static) initialized or not.
llvm-svn: 238960
New MipsAbiInfoHandler merges and hold both ELF header flags
and registries usage masks. In the future commits it will manage some
additional information.
llvm-svn: 238684
We do not need to merge ELF flags from DSO. But `isCompatible` is called
for all input files. So this change move ELF flags merging into the
MipsELFFile class.
llvm-svn: 238304
This patch fixes the R_AARCH64_TLSLE_ADD_TPREL_HI12 and R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
handling by using the correct offset by using the target layout along with
aarch64 alignments requirements.
It fixes the TLS test-suite SingleSource failures for aarch64:
* SingleSource/UnitTests/Threads/2010-12-08-tls.execution_time
* SingleSource/UnitTests/Threads/tls.execution_time
llvm-svn: 238258
Original patch of Shankar Easwaran with additional test case.
The yaml2obj does not allow to create an object file with non-unique
sections names so the fix uses a binary input object file in the test
case.
llvm-svn: 238115
These two serve different purpose:
PLTGOT entries are (usually) lazily resolved and serve as trampolines
to correctly call dynamically linked functions. They often have
R_*_JUMP_SLOT dynamic relocation type used.
Simple GOT entries hold other things, one of them may be
R_*_GLOB_DAT to correctly reference global and static data. This
is also used to hold dynamically linked function's address.
To properly handle cases when shared object's function is called
and at the same time its address is taken, we need to be able to have
both GOT and PLTGOT entries bearing different dynamic relocation types
for the same symbol.
llvm-svn: 238015
This is used when referencing global or static data in shared
objects. This is also used when function's address is taken and
function call is made indirectly.
llvm-svn: 238014
This patch provides generation of .ARM.exidx & .ARM.extab sections which are
used for unwinding. The patch adds new content type typeARMExidx for atoms from
.ARM.exidx section and integration of atoms with such type to the ELF
ReaderWriter. exidx.test has been added with checking of contents of .ARM.exidx
section and .ARM.extab section.
Differential Revision: http://reviews.llvm.org/D9324
llvm-svn: 236873
Change the test so that it tests the right functionality.
Also put a description with the code from which the test was generated.
Reported by Simon Atanasysan.
llvm-svn: 236334
I noticed that gold mark these as hidden. While at it I rewrote the test for
this feature to use yaml rather than an object file as input.
Differential Revision: http://reviews.llvm.org/D9418
Reviewed by: ruiu
llvm-svn: 236291
This patch allow the ARM relocation R_ARM_V4BX to be processed by lld,
although it is not really handled in the static relocation code. The
relocation is in the form:
Relocation section '.rel.text' at offset 0x428 contains 4 entries:
Offset Info Type Sym.Value Sym. Name
00000014 00000028 R_ARM_V4BX
Meaning it does have a direct target, but rather references to an absolute
section *ABS* (in this exemple to the .text segment itself). It makes the
target Atom after file parse to not have a associated pointer and thus
generating a derrefence NULL point in ELFFile<ELFT>::findAtom. Current
approach is just ignore and return nullptr in such cases.
The problem relies that default GCC configuration
for arm-linux-gnueabi{hf} emits the relocation for the asm:
--
.syntax unified
.arm
.p2align 2
.type fn, %function
fn:
ldr r3, .LGOT
ldr r2, .LGOT+4
.LPIC:
add r3, pc, r3
ldr r2, [r3, r2]
cmp r2, #0
bxeq lr
b __start__
.LGOT:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC+8)
.word __start__(GOT)
--
But only with the option -march=armv4 (which is the default GCC configuration).
For arm5 and forward the relocation is not created. This a special relocation
(defined miscellaneous for ARM) that instruct the linker to replace the bx
instruction into a mov. GNU linker has some options related to which substitution
it can create for such cases.
With this patch I can dynamically link an application against a GLIBC
arm-linux-gnueabi system configured with default GCC.
llvm-svn: 235880
loadFile could load mulitple files just because yaml has a feature for
putting multiple documents in one file.
Designing a linker around what yaml can do seems like a bad idea to
me. This patch changes it to read a single file.
There are further improvements to be done to the api and they
will follow shortly.
llvm-svn: 235724
According to the code model (ARM, Thumb, Thumb2) this patch updates the b/bl/blx 0 instructions with NOP.
test/elf/ARM/weak-branch.test has been added with tests for all available NOP (A1, T1, T2 encodings).
Differential Revision: http://reviews.llvm.org/D8807
llvm-svn: 235498
The TargetLayout class puts two sections into the same segment if they
have equal segment types and the same section flags (SHF_xxx). To be
able to merge some sort of sections into the same segment we drop some
flags before comparison. For example to merge string sections into Data
segment we drop SHF_STRINGS and SHF_MERGE flags.
The patch allows TargetLayout descendants to drop some target specific
section flags. MIPS target needs that to merge .MIPS.options section
which has SHF_MIPS_NOSTRIP flag into the LOAD segment.
http://reviews.llvm.org/D9160
llvm-svn: 235487
The `OutputSection::appendSection()` method always gets a pointer
to the `Section` class descendants. So it is not necessary to keep them
in the vector of `Chunk` pointers.
No functional changes.
llvm-svn: 235392
There's (almost) never need to keep .L symbols around for production
builds. In fact, the FreeBSD kernel explicitly specify -X beacuse the
size impact (and the subsequent performance impact) might be significant,
because we keep symbols in memory.
I was tempted to make this the default, but I haven't (yet).
PR: 23232
llvm-svn: 235357
HexagonEncodings.h contains a list of bitmasks. The file is used
only by HexagonRelocationHandler.cpp. The header is odd in the sense
that it uses struct Instruction but it doesn't define the data type.
This patch moves the struct definition to the header.
llvm-svn: 234947
This function is too long and complicated. Looks like new code was
added incrementaly without any refactoring. Maybe no one can describe
its exact semantics any more? It even contains copy-pastes inside it.
This patch is an (incomplete) attempt to simplify the function.
I tried to mechanically translate code to another form more intelligible.
I don't still understand the whole picture, but this patch shouldn't
change the linker's functionality.
llvm-svn: 234944
That helps to correctly write content of hash table if target and host
endianness are not the same. Right now that commit does not affect
any supported targets.
llvm-svn: 234928
We don't need to repeat the template argument. They are not
ambiguous. MIPS is parameterized for ELFT, so we can't do this
for MIPS, though.
llvm-svn: 234913
Rui Ueyama