Load Configuration field points to a structure containing information
for SEH. That data strucutre is not created by the linker but provided
by an external file. What we have to do is just to set __load_config_used
address to the header.
llvm-svn: 242427
If a symbol is exported as /export:foo, and foo is resolved as a
mangled name (_foo@<number> or ?foo@@Y...), that mangled name should
be written to the export table. Previously, we wrote the original
name to the export table.
llvm-svn: 242342
Because thunks for dllimported symbols contain absolute addresses on x86,
they need to be relocated at load-time. This bug was a cause of crashes
in DLL initialization routines.
llvm-svn: 242259
I am adding support for thin archives. On those, getting the buffer
involves reading another file.
Since we only need an id in here, use the member offset in the archive.
llvm-svn: 242205
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
Entry name selection rule is already complicated on x64, but it's more
complicated on x86 because of the underscore name mangling scheme.
If one of _main, _main@<number> (a C function) or ?main@@... (a C++ function)
is defined, entry name is _mainCRTStartup. If _wmain, _wmain@<number or
?wmain@@... is defined, entry name is _wmainCRTStartup. And so on.
llvm-svn: 242110
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
This is a direct port of the new PE/COFF linker to ELF.
It can take a single object file and generate a valid executable that executes at the first byte in the text section.
llvm-svn: 242088
If /delayload option is given, we have to resolve __delayLoadHelper2
since the function is the dynamic loader to delay-load DLLs.
The function name is mangled in x86 as ___delayLoadHelper2@8.
llvm-svn: 242078
clang-cl doesn't compile std::atomic_flag correctly (PR24101). Since the COFF
linker doesn't use threads yet, just revert r241420 and r241481 for now to
work around this clang-cl bug.
llvm-svn: 242006
With LLVM_ENABLE_THREADS disabled, all the llvm code assumes that it runs on
a single thread and doesn't use any mutexes. lld still spawned lots of threads
in that case and called into llvm, assuming that llvm is thread-safe.
As fix, let lld use only a single thread if LLVM_ENABLE_THREADS is disabled.
I left in all the mutexes in lld. That means lld is a bit slower than
necessary in single-thread mode, but that's probably worth the simpler code.
llvm-svn: 242004
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
Symbol foo is mangled as _foo in C and ?foo@@... in C++ on x86.
findMangle has to remove prefix underscore before mangle a given name
as a C++ symbol.
llvm-svn: 241874
Symbol names are usually mangled by appending "_" prefix on x86.
But the mangled name is not used in DLL export table. The export
table contains unmangled names.
llvm-svn: 241872
With this patch, LLD is now able to self-link an .exe file for x86
that runs correctly, although I don't think some headers (particularly
SEH) are not correct. DLL support is coming soon.
llvm-svn: 241857
Previously, we infer machine type at the very end of linking after
all symbols are resolved. That's actually too late because machine
type affects how we mangle symbols (whether or not we need to
add "_").
For example, /entry:foo adds "_foo" to the symbol table if x86 but
"foo" if x64.
This patch moves the code to infer machine type, so that machine
type is inferred based on input files given via the command line
(but not based on .directives files).
llvm-svn: 241843
Symbols exported by DLLs are listed in import library files.
Exported names may be mangled by "Import Name Type" field as
described in PE/COFF spec 7.3. This patch implements that
mangling scheme.
llvm-svn: 241719
This situation will only be temporary; I imagine we will eventually want to
have the new linker take the lld-link alias after we remove the old one.
However, I would like to port the CFI test suite in the compiler-rt
repository to Windows using the new COFF linker's LTO support; these tests
currently use gcc-style command lines and invoke the linker via the
compiler driver.
We can select the linker using the -fuse-ld flag, which Clang supports on
Windows, but it takes an executable name, rather than a list of arguments
(so "-fuse-ld=lld -flavor link2" wouldn't work), and it doesn't seem worth
the effort to extend the Clang driver to support arguments.
Differential Revision: http://reviews.llvm.org/D11031
llvm-svn: 241696
Providing a symbol table in the executable is quite useful when
debugging a fully-linked executable without having to reconstruct one
from DWARF.
Differential Revision: http://reviews.llvm.org/D11023
llvm-svn: 241689
Rui Ueyama