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
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
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
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
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
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
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
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
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
`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