| Age | Commit message (Collapse) | Author |
|---|
|
llvm-svn: 241477
|
|
TLS table header field is supposed to have address and size of TLS table.
The linker doesn't have to understand what TLS table is. TLS table's name
is always "_tls_used", so if there's that symbol, the linker simply sets
that symbol's RVA to the header. The size of the TLS table is always 40 bytes.
llvm-svn: 241426
|
|
This function is called SymbolTable::readObjects, so in order to
parallelize that function, we have to make this function thread-safe.
llvm-svn: 241420
|
|
Note that the linker is not multi-threaded yet.
This is a preparation for that.
llvm-svn: 241417
|
|
In the new design, mutation of Symbol pointers is the name resolution
operation. This patch makes them atomic pointers so that they can
be mutated by multiple threads safely. I'm going to use atomic
compare-exchange on these pointers.
dyn_cast<> doesn't recognize atomic pointers as pointers,
so we need to call load(). This is unfortunate, but in other places
automatic type conversion works fine.
llvm-svn: 241416
|
|
llvm-svn: 241397
|
|
/merge:.foo=.bar makes the linker to merge section .foo with section .bar.
llvm-svn: 241396
|
|
We were previously hitting assertion failures in the writer in cases where
a regular object file defined a weak external symbol that was defined by
a bitcode file. Because /export and /entry name mangling were implemented
using weak externals, the same problem affected mangled symbol names in
bitcode files.
The underlying cause of the problem was that weak external symbols were
being resolved before doing LTO, so the symbol table may have contained stale
references to bitcode symbols. The fix here is to defer weak external symbol
resolution until after LTO.
Also implement support for weak external symbols in bitcode files
by modelling them as replaceable DefinedBitcode symbols.
Differential Revision: http://reviews.llvm.org/D10940
llvm-svn: 241391
|
|
sections."
This reverts commit r241386 because the issue is addressed in LLVM (r241387).
llvm-svn: 241388
|
|
Looks like clang-cl sets a bogus value to the field, which makes
getSectionContents() to truncate section contents. This patch directly
uses SizeOfRawData field instead of VirtualSize to see if this can
make buildbot green.
llvm-svn: 241386
|
|
llvm-svn: 241385
|
|
llvm-svn: 241384
|
|
GC root may have non-regular defined symbols, such as DefinedImportThunk,
so this cast<> was a wrong assumption.
llvm-svn: 241382
|
|
llvm-svn: 241379
|
|
llvm-svn: 241378
|
|
This worked before, but only by accident, and only with assertions disabled.
We ended up storing a DefinedRegular symbol in the WeakAlias field,
and never using it as an Undefined.
Differential Revision: http://reviews.llvm.org/D10934
llvm-svn: 241376
|
|
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
|
|
llvm-svn: 241346
|
|
No functional changes.
llvm-svn: 241342
|
|
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 change cut the link time of chrome.dll from 24 seconds
to 22 seconds (5% gain). When the control reaches end of link(),
all output files have already been written. All in-memory
objects can just vanish. There is no use to call their dtors.
llvm-svn: 241320
|
|
DLLs can export symbols only by ordinal, and DLLs are also able to be
delay-loaded. The combination of the two is valid. I didn't expect
that combination. This patch implements that feature.
With this patch, LLD is now able to link a working executable of Chrome
for 64-bit debug build. The browser seemed to be working fine. Chrome is
good for testing because of its variety and size. It contains various
open-source libraries written by various people. The largest file in
Chrome is chrome.dll whose size is 496MB. LLD can link it in 24 seconds.
MSVC linker takes 48 seconds. So it is exactly 2x faster. (I measured
that with debug info and ICF being turned off.)
With this achievement, I think I can say that the new COFF linker is
now mostly feature complete for x86-64 Windows. I believe there are
still many lingering bugs, though.
llvm-svn: 241318
|
|
llvm-svn: 241316
|
|
Previously, __ImageBase symbol got a different value than the one
specified by /base:<number> because the symbol was created in the
SymbolTable's constructor. When the constructor is called,
no command line options are processed yet, so the symbol was
created always with the initial value. This caused wrong relocations
and thus caused mysterious crashes of some executables linked by LLD.
llvm-svn: 241313
|
|
llvm-svn: 241311
|
|
llvm-svn: 241298
|
|
Previously, pointers pointed by locally-imported symbols were broken.
It has only 4 bytes although the correct size is 8 byte. This patch
fixes that bug.
llvm-svn: 241295
|
|
Previously, SymbolBody::compare(A, B) didn't satisfy weak ordering.
There was a case that A < B and B < A could have been true.
This is because we just pick LHS if A and B are consisdered equivalent.
This patch is to make symbols being weakly ordered. If A and B are
not tie, one of A < B && B > A or A > B && B < A is true.
This is not an improtant property for a single-threaded environment
because everything is deterministic anyways. However, in a multi-
threaded environment, this property becomes important.
If a symbol is defined or lazy, ties are resolved by its file index.
For simple types that we don't really care about their identities,
symbols are compared by their addresses.
llvm-svn: 241294
|
|
llvm-svn: 241274
|
|
llvm-svn: 241238
|
|
On Windows, we have four different main functions, {w,}{main,WinMain}.
The linker has to choose a corresponding entry point function among
{w,}{main,WinMain}CRTStartup. These entry point functions are defined
in the standard library. The linker resolves one of them by looking at
which main function is defined and adding a corresponding undefined
symbol to the symbol table.
Object files containing entry point functions conflicts each other.
For example, we cannot resolve both mainCRTStartup and WinMainCRTStartup
because other symbols defined in the files conflict.
Previously, we inferred CRT function name at the very end of name
resolution. I found that that is sometimes too late. If the linker
already linked one of these four archive member objects, it's too late
to change the decision.
The right thing to do here is to infer entry point name after adding
all symbols from command line files and before adding any other files
(which are specified by directive sections). This patch does that.
llvm-svn: 241236
|
|
Previously, we use SymbolTable::rename to resolve AlternateName symbols.
This patch is to merge that mechanism with weak aliases, so that we
remove that function.
llvm-svn: 241230
|
|
The previous name was too long to my taste.
llvm-svn: 241215
|
|
I think Undefined symbols are a bit more convenient than StringRefs
since SymbolBodies are handles for symbols. You can get resolved
symbols for undefined symbols just by calling getReplacmenet without
looking up the symbol table.
llvm-svn: 241214
|
|
Occasionally we have to resolve an undefined symbol to its
mangled symbol. Previously, we did that on calling side of
findMangle by explicitly updating SymbolBody.
In this patch, mangled symbols are handled as weak aliases
for undefined symbols.
llvm-svn: 241213
|
|
llvm-svn: 241198
|
|
llvm-svn: 241194
|
|
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
|
|
llvm-svn: 241157
|
|
llvm-svn: 241128
|
|
Previously, the order of adding symbols to the symbol table was simple.
We have a list of all input files. We read each file from beginning of
the list and add all symbols in it to the symbol table.
This patch changes that order. Now all archive files are added to the
symbol table first, and then all the other object files are added.
This shouldn't change the behavior in single-threading, and make room
to parallelize in multi-threading.
In the first step, only lazy symbols are added to the symbol table
because archives contain only Lazy symbols. Member object files
found to be necessary are queued. In the second step, defined and
undefined symbols are added from object files. Adding an undefined
symbol to the symbol table may cause more member files to be added
to the queue. We simply continue reading all object files until the
queue is empty.
Finally, new archive or object files may be added to the queues by
object files' directive sections (which contain new command line
options).
The above process is repeated until we get no new files.
Symbols defined both in object files and in archives can make results
undeterministic. If an archive is read before an object, a new member
file gets linked, while in the other way, no new file would be added.
That is the most popular cause of an undeterministic result or linking
failure as I observed. Separating phases of adding lazy symbols and
undefined symbols makes that deterministic. Adding symbols in each
phase should be parallelizable.
llvm-svn: 241107
|
|
llvm-svn: 241089
|
|
llvm-svn: 241075
|
|
llvm-svn: 241031
|
|
Differential Revision: http://reviews.llvm.org/D10827
llvm-svn: 241029
|
|
The size of this class actually matters because this is the
most popular class among all classes. We create a Defined symbol
for each defined symbol in a symbol table. That can be millions
for a large program. For example, linking LLD instantiates this
class millions times.
llvm-svn: 241025
|
|
directives ourselves.
llvm-svn: 241020
|
|
llvm-svn: 241011
|
|
llvm-svn: 241008
|
