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
On Windows, we have to create a .lib file for each .dll.
When linking against DLLs, the linker doesn't use the DLL files,
but instead read a list of dllexported symbols from corresponding
lib files.
A library file containing descriptors of a DLL is called an
import library file.
lib.exe has a feature to create an import library file from a
module-definition file. In this patch, we create a module-definition
file and pass that to lib.exe.
We eventually want to create an import library file by ourselves
to eliminate dependency to lib.exe. For now, we just use the MSVC
tool.
llvm-svn: 239937
Module-definition files (.def files) are yet another way to
specify parameters to the linker. You can write a list of dllexported
symbols in module-definition files instead of using /export command
line option. It also supports a few more directives.
The parser code is taken from lib/Driver/WinLinkModuleDef.cpp
with the following modifications.
- variable names are updated to comply with the LLVM coding style.
- Instead of returning parsing results as "directive" objects,
it updates Config object directly.
llvm-svn: 239929
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
DLL files are in the same format as executables but they have export tables.
The format of the export table is described in PE/COFF spec section 5.3.
A new class, EdataContents, takes care of creating chunks for export tables.
What we need to do is to parse command line flags for dllexports, and then
instantiate the class to create chunks. For the writer, export table chunks
are opaque data -- it just add chunks to .edata section.
llvm-svn: 239869
We are currently handling all combinations of SymbolBody types directly.
This patch is to flip this and Other if Other->kind() < this->kind()
to reduce number of combinations. No functionality change intended.
llvm-svn: 239745
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
PE/COFF executables/DLLs usually contain data which is called
base relocations. Base relocations are a list of addresses that
need to be fixed by the loader if load-time relocation is needed.
Base relocations are in .reloc section.
We emit one base relocation entry for each IMAGE_REL_AMD64_ADDR64
relocation.
In order to save disk space, base relocations are grouped by page.
Each group is called a block. A block starts with a 32-bit page
address followed by 16-bit offsets in the page. That is more
efficient representation of addresses than just an array of 32-bit
addresses.
llvm-svn: 239710
When we add a chunk to an OutputSection, we always want to create
a backreference from an OutputSection to a Chunk. To make sure
we always do, do that in addChunk(). NFC.
llvm-svn: 239706
Resource files are data files containing i18n messages, icon images, etc.
MSVC has a tool to convert a resource file to a regular COFF file so that
you can just link that file to embed resources to an executable.
However, you can directly pass resource files to the linker. If you do that,
the linker invokes the tool automatically. This patch implements that feature.
llvm-svn: 239704
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
In the case where either a bitcode file and a regular file or two bitcode
files export a common or comdat symbol with the same name, the linker needs
to pick one of them following COFF semantics. This patch implements a design
for resolving such symbols that pushes most of the work onto either LLD's
regular mechanism for resolving common or comdat symbols or the IR linker's
mechanism for doing the same.
We modify SymbolBody::compare to always prefer non-bitcode symbols, so that
during the initial phase of symbol resolution, the symbol table always contains
a regular symbol in any case where we need to choose between a regular and
a bitcode symbol. In SymbolTable::addCombinedLTOObject, we force export
any bitcode symbols that were initially pre-empted by a regular symbol,
and later use SymbolBody::compare to choose between the regular symbol in
the symbol table and the regular symbol from the combined LTO object file.
This design seems to be sound, so long as the resolution mechanism is defined
to be commutative and associative modulo arbitrary choices between symbols
(which seems to be the case for COFF).
Differential Revision: http://reviews.llvm.org/D10329
llvm-svn: 239563
isRoot, isLive and markLive functions are called very frequently.
Previously, they were virtual functions. This patch make them
non-virtual.
Also this patch checks chunk liveness before calling its mark().
Previously, we did that at beginning of markLive(), so the virtual
function would return immediately if it's live. That was inefficient.
llvm-svn: 239458
The code generator may create references to runtime library symbols such as
__chkstk which were not visible via LTOModule. Handle these cases by loading
the object file from the library, but abort if we end up having loaded any
bitcode objects.
Because loading the object file may have introduced new undefined references,
call reportRemainingUndefines again to detect and report them.
Differential Revision: http://reviews.llvm.org/D10332
llvm-svn: 239386
The LLVM code generator can sometimes synthesize symbols, such as SSE
constants, that are not visible via the LTOModule interface. Allow such
symbols so long as they have definitions.
Differential Revision: http://reviews.llvm.org/D10331
llvm-svn: 239385
This change seems to make the linker about 10% faster.
Reading symbol name is not very cheap because it needs strlen()
on the string table. We were wasting time on reading non-external
symbol names that would never be used by the linker.
llvm-svn: 239332
MSVC profiler reported that this stable_sort takes 7% time
when self-linking. As a result, createSection was taking 10% time.
Now createSection takes 3%. This small change actually makes
the linker a bit but perceptibly faster.
llvm-svn: 239292
We forgot to check for auxiliary symbol's type. So we sometimes read
garbage as associative section definitions.
Associative sections are considered as not live themselves by the
garbage collector because they are live only when associaited sections
are live.
By reading more data (or garbage) as associative section definitions,
we treated more sections as non-GC-roots, that caused the linker to
discard too many sections by mistake. That caused another mysterious
bug (such as some global constructors don't run at all for some reason.)
llvm-svn: 239287
I don't know what the right thing to do here, but at least 1 does
not seem like a correct value. If we do not align common chunks at
all, a small program which calls puts() from global dtors crashes
mysteriously in a kernel32's function.
I believe the crash was caused by symbols overlapping each other,
and my guess is that alignment has something to do with that, but
I am not 100% sure. Needs investigating.
llvm-svn: 239280
Chunk has writeTo function which takes uint8_t *Buf.
writeHeaderTo feels more consistent with that because this member
function also takes uint8_t *Buf.
llvm-svn: 239236
Previously, half of the constructor for .idata contents was in Chunks.cpp
and the rest was in Writer.cpp. This patch moves the latter to Chunks.cpp.
Now IdataContents class manages everything for .idata section.
llvm-svn: 239230
In this design, Chunk is the only thing that knows how to write
its contents to output file as well as how to apply relocations
there. The writer shouldn't know about the details.
llvm-svn: 239216
This test case uses too large addends in relocations. Now the test is correct.
Later we need to implement overflow checking to catch such cases.
llvm-svn: 239177
For some reason llvm's r239045 made lld propagate data_1's size. This indicates
a bug somewhere in lld.
I hesitated between changing the test or just checking in a .o produced with
the old llvm-mc. Since the size is now correct, it seemed better to update the
test.
llvm-svn: 239067
Not only entry point symbol but also symbols specified by /include
option must be preserved, as they will never be dead-stripped.
http://reviews.llvm.org/D10220
llvm-svn: 239005
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
Avoid saying this is based on sections because it's not very accurate.
That we don't split section into smaller chunks of data does not mean
that the linker is built on top of that.
In reality, most part of the code do not care about underlying data,
so they are neither based on "atoms" nor sections.
The symbol table only cares about symbol names and their types.
The writer handles list of chunks, which look like just blobs,
and the writer doesn't care what those chunks are backed by.
The only thing that interact with sections is SectionChunk, which is
abstracted away as one type of Chunk.
llvm-svn: 238902
In r238690, I made all files have only MemoryBufferRefs. This change
is to do the same thing for the bitcode file reader. Also updated
a few variable names to match with other code.
llvm-svn: 238782
Symbols exported by DLLs can be imported not by name but by
small number or ordinal. Usually, symbols have both ordinals
and names, and in that case ordinals are called "hints" and
used by the loader as hints.
However, symbols can have only ordinals. They are called
import-by-ordinal symbols. You need to manage ordinals by hand
so that they will never change if you choose to use the feature.
But it's supposed to make dynamic linking faster because
it needs no string comparison. Not sure if that claim still
stands in year 2015, though. Anyways, the feature exists,
and this patch implements that.
llvm-svn: 238780
I'm adding ordinal-only (nameless) imports to the import table.
The chunk for that type is going to be different from LookupChunk.
Without this change, we cannot add objects of the new type to the
vectors.
llvm-svn: 238779
Instead of returning non-categorized errors, return categorized errors.
All uses of make_dynamic_error_code are removed.
Because we don't have error reporting mechanism, I just chose to print out
error messages to stderr, and then return an error object. Not sure if
that's the right thing to do, but at least it seems practical.
http://reviews.llvm.org/D10129
llvm-svn: 238714
Previously, this feature was implemented using a special type of
undefined symbol, in addition to an intricate way to make the resolver
read a virtual file containing that renaming symbols.
Now the feature is directly handled by the symbol table.
The symbol table has a function, rename(), to rename symbols, whose
definition is 4 lines long. Symbol renaming is naturally modeled using
Symbol and SymbolBody.
llvm-svn: 238696
Previously, a MemoryBuffer of a file was owned by each InputFile object.
This patch makes the Driver own all of them. InputFiles now have only
MemoryBufferRefs. This change simplifies ownership managment
(particularly for ObjectFile -- the object owned a MemoryBuffer only when
it's not created from an archive file, because in that case a parent
archive file owned the entire buffer. Now it owns nothing unconditionally.)
llvm-svn: 238690
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
It does not involve notions of virtual archives or virtual files,
nor store a list of undefined symbols somewhere else to consume them later.
We did that before. In this patch, undefined symbols are just added to
the symbol table, which now can be done in very few lines of code.
llvm-svn: 238681
Previously the main linker routine is just a non-member function.
We store some context information to the Config object.
This patch makes it belong to Driver.
llvm-svn: 238677
`main` is not the only main function in Windows. You can choose one
from these four -- {w,}{WinMain,main}. There are four different entry
point functions for them, {w,}{WinMain,main}CRTStartup, respectively.
The linker needs to choose the right one depending on which `main`
function is defined.
llvm-svn: 238667
Section names were truncated to 8 bytes because the section table's
name field is 8 byte long. This patch creates the string table to
store long names.
llvm-svn: 238661
The new mechanism is less code, and fixes the case where all inputs
are archives.
Differential Revision: http://reviews.llvm.org/D10136
llvm-svn: 238618
Currently we set the field to zero, but as per the spec, we should
set numbers we read from import library files. The loader uses the
values as starting offsets for binary search when looking up imported
symbols from DLL.
llvm-svn: 238562
The previous implementation's driver file is cluttered by lots of
small functions, and it was hard to find important functions.
Make a separate file to prevent that issue.
llvm-svn: 238482
Previously Writer directly handles writes to a file.
Chunks needed to give Writer a continuous chunk of memory.
That was inefficent if you construct data in chunks because
it would require two memory copies (one to construct a chunk
and the other is to write that to a file).
This patch teaches chunk to write directly to a file.
From readability point of view, this is also good because
you no longer have to call hasData() before calling getData().
llvm-svn: 238464
This is an initial patch for a section-based COFF linker.
The patch has 2300 lines of code including comments and blank lines.
Before diving into details, you want to start from reading README
because it should give you an overview of the design.
All important things are written in the README file, so I write
summary here.
- The linker is already able to self-link on Windows.
- It's significantly faster than the existing implementation.
The existing one takes 5 seconds to link LLD on my machine,
while the new one only takes 1.2 seconds, even though the new
one is not multi-threaded yet. (And a proof-of-concept multi-
threaded version was able to link it in 0.5 seconds.)
- It uses much less memory (250MB vs. 2GB virtual memory space
to self-host).
- IMHO the new code is much simpler and easier to read than
the existing PE/COFF port.
http://reviews.llvm.org/D10036
llvm-svn: 238458
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
It's a lot faster than bash.
Also use FileCheck instead of grep to search through a binary file.
Cygwin's grep isn't working here for unknown reasons that probably
aren't worth investigating.
llvm-svn: 237834
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
Command line options --arm-target1-rel and --arm-target1-abs have been renamed to be compatible with GNU linkers.
Two tests have been updated:
test/elf/options/target-specific-args.test
test/elf/ARM/rel-arm-target1.test
Differential Revision: http://reviews.llvm.org/D9037
llvm-svn: 235499
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
Before we only accepted --dynamic-linker=<file> and -dynamic-linker <file>
but older versions of GNU ld (e.g. 2.17.50) accept this other form, so
try to be compatible.
PR: 23233
llvm-svn: 235282
Simon Atanasyan