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
This patch tries to fix the following MSVC warning.
warning C4661: 'bool
lld:🧝:ELFFile<lld:🧝:ELF32LE>::isCompatible(unsigned
char,unsigned char)' : no suitable definition provided for explicit
template instantiation request
llvm-svn: 234909
Previously, ELFReader takes three template arguments: EFLT,
LinkingContextT and FileT. FileT is itself templated.
So it was a bit complicated. Maybe too much.
Most architectures don't actually need to be parameterized for ELFT.
For example, x86 is always ELF32LE and x86-64 is ELF64LE.
However, because ELFReader requires a ELFT argument, we needed
to parameterize a class even if not needed.
This patch removes the parameter from the class. So now we can
de-templatize such classes (I didn't do that in this patch, though).
This patch also removes ContextT parameter since it didn't have to be
passed as a template argument.
llvm-svn: 234853
The function took either StringRef or Twine. Since string literals are
ambiguous when resolving the overloading, many code calls used this
function with explicit type conversion. That led awkward code like
make_dynamic_error_code(Twine("Error occurred")).
This patch adds a function definition for string literals, so that
you can directly call the function with literals.
llvm-svn: 234841
DynamicFile and ELFFile are instantiated for four different types,
ELF{32,64}{BE,LE}. Because the classes are instantiated in each
compilation unit, including the header file makes object files
10MB larger.
On Windows, issue of excessive template instantiation is critical,
since the regular COFF file supports only up to 65534 sections.
(We could use the extended COFF file format, but generating that
much COMDAT sections is not a good thing in the first place
because it means long compile time and long link time.)
I confirmed that this change makes AArch64TargetHandler.cpp.o
from 21MB to 8.5MB. It feels still too large, but I think it's
a good start.
llvm-svn: 234808
This is a follow-up to r234728 and r234729. It looks like explicit
instantiation of `MipsELFFile` is redundant and triggers Visual C++ warning.
llvm-svn: 234756
This patch adds support for overflow checking when processing
R_AARCH64_CALL26, R_AARCH64_JUMP26, R_AARCH64_CONDBR19,
R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21, and R_AARCH64_TLSLE_ADD_TPREL_HI12
relocations.
llvm-svn: 234749
This patch makes the AArch64GotAtomContent, AArch64Plt0AtomContent, and
AArch64PltAtomContent static and also cleanup their formatting.
llvm-svn: 234745
I can't access my Windows machine at the moment, but the build was breaking with:
c:\b\build\slave\crwinclanglld\build\src\third_party\llvm\tools\lld\lib\readerwriter\elf\mips\MipsTargetLayout.h(38) : error C2440: 'return' : cannot convert from 'lld:🧝:MipsGOTSection<ELFT> *' to 'lld:🧝:AtomSection<ELFT> *'
with
[
ELFT=lld:🧝:Mips32ELType
]
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
I think this regressed caused in 234727: that the forward-declarations
of MipsGOTSection<> is not enough.
llvm-svn: 234736
Right now MIPS instantiates MipsTargetHandler using Mips32ELType and
Mips64ELType. And in the future we can add a couple more types. That
leads to the large object file size because compiler has to create
copies of MipsTargetHandler and all realted classes for each types used
for instantiation.
The patch introduces two factory functions and puts each of them into
the separate cpp file. That allows to reduce size of single object file.
llvm-svn: 234728
This doesn't compile with MSVC 2013:
include\lld/ReaderWriter/PECOFFLinkingContext.h(356) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
include\lld/ReaderWriter/PECOFFLinkingContext.h(357) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
llvm-svn: 234676
I believe this patch eliminates all remaining uses of _context
or _linkingContext variable names. Consistent naming improves
readability.
llvm-svn: 234645
The Native file format was designed to be the fastest on-memory or
on-disk file format for object files. The problem is that no one
is working on that. No LLVM tools can produce object files in
the Native, thus the feature of supporting the format is useless
in the linker.
This patch removes the Native file support. We can add it back
if we really want it in future.
llvm-svn: 234641
This MIPS specific option controls R_MIPS_EH relocation handling.
If -pcrel-eh-reloc is specified R_MIPS_EH relocation should be handled
like R_MIPS_PC32 relocation.
llvm-svn: 234635
The patch supports just the R_MIPS_EH relocation handling and does not
implement full specification of compact exception tables for MIPS ABIs.
llvm-svn: 234634
When we call getGP() we need in fact _gp symbol address. Let's cache its
value and return it directly from the new getGPAddr() function.
llvm-svn: 234632
Because calls of applyRelocation is parallelized, all functions
called from that need to be thread-safe. This piece of code
didn't use any synchronization mechanism, so it was not safe.
llvm-svn: 234628
This includes implementation of PLT0 entry.
For testing, libfn.so binary is added since
there's no way to link shared objects with lld yet.
llvm-svn: 234588
Because no one except Hexagon uses the header, we don't need to maintain
the header in the common directory. Also de-template the function for
readability.
llvm-svn: 234551
CreateELF.h was included only by ELFReader.h, and it was used only
by ELFReader class. By making the function a member of the class,
we can remove template parameters.
llvm-svn: 234540
atom_collection is basically a wrapper for std::vector. The class
provides begin and end member functions, so that it "hides" the
other member functions provided by std::vector. However, you can
still directly access _atoms member since the member is not
protected.
We cannot simply make the member private because we need that member
when we are constructing atom vectors.
This patch splits atom_collection into two types: std::vector<Atom *>
and AtomRange. When we are constructing atom vectors, we use the
former class. We return instances of the latter class from File
objects so that callers cannot add or remove atoms from the lists.
std::vector<Atom *> is automatically converted to AtomRange.
llvm-svn: 234450
It's a follow-up to r234347. We do not need to keep a reference to
`GOTFile` instance in a xxxWriter class after ownership is transferred
to the caller of the `createImplicitFiles` method.
llvm-svn: 234396
SimpleFile defines defined(). undefined(), sharedLibrary() and absolute().
We should use the class instead of deriving from the base class and
re-defining the member functions in ELFFile.
llvm-svn: 234367
Now 'writer' creates an instance of `RuntimeFile` in the constructor, then
populates the file in the virtual function `addDefaultAtoms`, then pass
owning of this file to the caller of virtual function `createImplicitFiles`.
First, we do not need to keep an instance of `RuntimeFile` so long. It is
enough to create the file, right after that populate it and pass the owning.
Second, relationship between `createImplicitFiles` and `addDefaultAtoms`
is complicated. The `createImplicitFiles` might call `addDefaultAtoms`,
overridden version of `addDefaultAtoms` might call base class `addDefaultAtoms`,
and overridden version of `createImplicitFiles` might call base class
`createImplicitFiles` as well as `addDefaultAtoms`.
The patch solves both problems above. It creates and populates runtime files
right in the createImplicitFiles(), removes `addDefaultAtoms` at all and
does not keep references to runtime files in class fields.
llvm-svn: 234347
Make PLT entry atoms represent mapping symbols in the Release mode,
while in the Debug mode they are still function-like symbols
with regular names.
It's legal that mapping symbols denote unnamed parts of code,
and PLT entries are not required to have function-like names.
Differential Revision: http://reviews.llvm.org/D8819
llvm-svn: 234301
Maybe we can interpret alignment 0 as "don't care", but for
consistency, it's good to set 1 instead of 0 where we allow
any alignments.
llvm-svn: 234284
Denis Protivensky