If /subsystem:windows is passed, link.exe only looks for WinMain and wWinMain,
and if /subsystem:console is passed it only looks for main and wmain. lld-link
used to look for all 4 in both cases. This patch makes lld-link match
link.exe's behavior.
This requires that the subsystem is known by the time findDefaultEntry() gets
called. findDefaultEntry() is called before the main link loop, so that the
loop can mark the entry point as undefined. That means inferSubsystem() has to
be called above the main loop as well. This in turn means /subsystem: from
.drectve sections only has an effect on entry point inference for obj files
passed to lld-link directly (and not in obj files found later in .lib files).
link.exe seems to ignore /subsystem: for obj files from lib files completely
(while in lld it's ignored only for entry point detection but it still
overrides /subsystem: flags passed on the command line for the value that gets
written in the output file).
Also, if the subsytem isn't needed (e.g. when only writing a /def: lib file and
not writing a coff file), link.exe doesn't complain if the subsystem isn't
known, so both subsystem and entry point handling should be below the early
return lld has for that case.
Fixes PR36523.
https://reviews.llvm.org/D50316
llvm-svn: 339165
Summary: To be consistent with other files where only SignExtend64 is used.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50366
llvm-svn: 339083
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This is a companion change to: https://reviews.llvm.org/D50206
Reviewers: asmith, zturner, espindola
Subscribers: emaste, sbc100, arichardson, aheejin, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D50282
llvm-svn: 339075
GNU ld's manual says that TARGET(foo) is basically an alias for
`--format foo` where foo is a BFD target name such as elf64-x86-64.
Unlike GNU linkers, lld doesn't allow arbitrary BFD target name for
--format. We accept only "default", "elf" or "binary". This makes
situation a bit tricky because we can't simply make TARGET an alias for
--target.
A quick code search revealed that the usage number of TARGET is very
small, and the only meaningful usage is to switch to the binary mode.
Thus, in this patch, we handle only TARGET(elf.*) and TARGET(binary).
Differential Revision: https://reviews.llvm.org/D48153
llvm-svn: 339060
MinGW configurations don't use associative comdats, as GNU ld doesn't
support that. Instead they produce normal comdats named .text$sym,
.xdata$sym and .pdata$sym.
GNU ld doesn't discard any comdats starting with .xdata or .pdata,
even if --gc-sections is used (while it does discard other unreferenced
comdats), regardless of what symbol name is used after the $ separator.
For LLD, treat any such comdat as implicitly associative to the base
symbol. This requires maintaining a map from symbol name to section
number, but that is only maintained when the MinGW flag has been
enabled.
Differential Revision: https://reviews.llvm.org/D49700
llvm-svn: 339058
It's not an error if a common symbol (uninitialized data, with alignment
specified via the aligncomm directive) is replaced with a regular
one with initialized data (with alignment specified via the section
chunk).
Differential Revision: https://reviews.llvm.org/D50268
llvm-svn: 339049
--export now implies --undefined
This is really a requirement from emscripten but I think it
makes sense in general too.
Differential Revision: https://reviews.llvm.org/D50287
llvm-svn: 339047
During copy relocation of a variable defined in a DSO, if a TLS variable in that DSO happens to have the same st_value, it would also be copied. This was unnecessary because the addresses of TLS variables are relative to TLS segment. They don't interfere with non-TLS variables.
This copying behavior can be harmful in the following scenario:
For function-scope thread-local variables with non-trivial constructors,
they have guard variables. In the case of x86_64 general-dynamic model:
template <int N>
void foo() {
thread_local std::string a;
}
GOT[n] R_X86_64_DTPMOD64 guard variable for a
GOT[n+1] R_X86_64_DTPOFF64 guard variable for a
GOT[n+2] R_X86_64_DTPMOD64 a
GOT[n+3] R_X86_64_DTPOFF64 a
a and its guard variable are both represented as TLS variables, which
should be within the same module. If one is copy relocated to the main
module while the other is not, their module ID will mismatch and can
cause access without prior construction.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50289
llvm-svn: 339042
Some parts of the code changed are a bit old. I found traces in 2016.
Initiall commits has test cases and perhaps reasonable comments.
For example, we had segfaults earlier and had the code to fix them.
Now, in 2018, I think it is excessive to have these parts, because
we do not have segfaults and our code was changed a lot (softly saying).
I reviewed the current sources and I think that at this point of the
execution flow, we should never face with
the conditions checked and so I removing them in this patch.
This helps to cleanup the code.
llvm-svn: 339003
Add a test for the R_ARM_THM_JUMP11 relocation to an undefined symbol. We
have to use yaml2obj as llvm-mc relaxes the narrow branch to a b.w which
uses the R_ARM_THM_JUMP24 relocation instead.
Differential Revision: https://reviews.llvm.org/D50234
llvm-svn: 338999
Summary:
Optimization remark format is slightly changed by LLVM patch D49412.
One test is fixed with expected messages changed.
Frankly speaking I have not tested this change yet. I will test when manage to setup the project.
Reviewers: xbolva00, espindola
Reviewed By: xbolva00
Subscribers: emaste, arichardson, steven_wu, dexonsmith
Differential Revision: https://reviews.llvm.org/D50242
llvm-svn: 338970
This simplifies the code a bit.
It is NFC except that it removes early exit for Count == 0
which does not seem to be useful (we have no such tests either).
Differential revision: https://reviews.llvm.org/D49136
llvm-svn: 338953
This matches the behavior of the ELF linker where -u/--undefined
means symbols will get pulled in from archives but won't result
in link error if they are missing.
Also, don't actually great symbol table entries for the undefined
symbols, again matching more closely the ELF linker.
This also results in simplification of the code.
Differential Revision: https://reviews.llvm.org/D50279
llvm-svn: 338938
LinkerDriver::inferSubsystem() used to do Symtab->findUnderscore("WinMain"),
but WinMain is stdcall in 32-bit and is hence is called _WinMain@16. Instead,
Symtab->findMangle(mangle("WinMain")) needs to be called.
But since LinkerDriver::inferSubsystem() and LinkerDriver::findDefaultEntry()
both need to call this, introduce a common helper function for this and call it
from both places. (Also call it for "main" for consistency, even though
findUnderscore() is enough for main since that's __cdecl on 32-bit).
This also exposed a bug for /nodefaultlib entrypoint inference: The code here
called findMangle(Sym) instead of findMangle(mangle(Sym)), again doing the
wrong thing on 32-bit. Fix that too.
While here, make Driver::mangle() a static free function.
https://reviews.llvm.org/D50184
llvm-svn: 338877
In according to the comment, undefined symbol should never reach there.
So, should be able to remove the check. I am assuming this is NFC.
llvm-svn: 338723
It does not seem that this code is alive.
I seems was needed previously but we fixed it.
If it is still needed, it needs new tests,
but for now I do not know how to trigger it,
and so I removed it.
llvm-svn: 338713
Some lit tests that call llvm-ar use the 'r' flag. If the target archive
already exists and is in a corrupt state, this can cause the test to fail. We
have added 'rm -f' calls before the llvm-ar calls to increase the
robustness of the tests.
Differential revision: https://reviews.llvm.org/D49184
llvm-svn: 338705
Patch by Konstantin Schwarz!
If more than a single output section is added to a PT_LOAD header,
only the first section should set the LMAOffset of the segment.
Otherwise, we get a load-address overlap error
Differential revision: https://reviews.llvm.org/D50133
llvm-svn: 338697
Patch by Konstantin Schwarz!
If both the MemRegion and LMARegion are set for an output section in
a linker script, we should only increase the LMARegion if it is
different from the MemRegion. Otherwise, we reserve the memory twice.
Differential revision: https://reviews.llvm.org/D50065
llvm-svn: 338684
Patch by Konstantin Schwarz!
The condition to create a new phdr must also check the usage of "AT>"
linker script command, and create a new PT_LOAD header if a new LMARegion is used.
This fixes PR38307
Differential revision: https://reviews.llvm.org/D50052
llvm-svn: 338679
This was useful for LTO bringup in lld-link while lld couldn't write PDBs. Now
that it can, this should no longer be needed. Hopefully the flag is obscure
enough and recent enough, that nobody uses it – but if somebody should use it,
they should be able to just stop passing it and things should continue to work.
https://reviews.llvm.org/D50139
llvm-svn: 338615
This reverts commit r338596 because it contained a functional change.
The patch accidentally replaced StringRef::startswith with the exact match.
llvm-svn: 338600
Some test setups run tests in a read-only path, which means that opening the
default output path (a.out) for write will fail. This change adds appropriate -o
flags so the tests will not fail spuriously.
llvm-svn: 338440
If any of our inputs are bitcode files, the LTO code generator may create
references to certain library functions that might not be explicit in the
bitcode file's symbol table. If any of those library functions are defined
in a bitcode file in an archive member, we need to arrange to use LTO to
compile those archive members by adding them to the link beforehand.
Differential Revision: https://reviews.llvm.org/D50017
llvm-svn: 338434
Nico Weber