If /subsystem option is not given, the linker needs to infer the
subsystem based on the entry point symbol. If it fails to infer
that, the linker should error out on it.
LLD was almost correct, but it would fail to infer the subsystem
if the entry point is specified with /entry. This is because the
subsystem inference was coupled with the entry point function
searching (if no entry point name is specified, the linker needs
to find the right entry name).
This patch makes the subsystem inference an independent pass to
fix the issue. Now, as long as an entry point function is defined,
LLD can infer the subsystem no matter how it resolved the entry
point.
I don't think scanning all the defined symbols is fast, although
it shouldn't be that slow. The file class there does not provide
any easy way to find an atom by name, so this is what we can do
at this moment. I'd like to revisit this later to make it more
efficient.
llvm-svn: 221499
No functionality change. This removes a down-cast from LinkingContext to
MachOLinkingContext.
Also, remove const from LinkingContext::createImplicitFiles() to remove
the need for another const cast. Seems reasonable for createImplicitFiles()
to need to modify the context (MachOLinkingContext does).
llvm-svn: 218796
Previously we emit two or more identical definitions for an
exported symbol if the same /export option is given more than
once. This patch fixes that bug.
llvm-svn: 218433
/machine:ebc was previously recognized but rejected. Unknown architecture
names were handled differently but eventually rejected too. We don't need
to distinguish them.
llvm-svn: 218344
This patch changes the type of export table set from std::set to
std::vector. The new code is slightly inefficient, but because
export table elements are actually mutable, std::vector is better
here. No functionality change.
llvm-svn: 218343
If two or more /export options are given for the same symbol, we should
always print a warning message and use the first one regardless of other
parameters.
Previously there was a case that the first parameter is not used.
llvm-svn: 218342
Accept /machine:arm as an argument. This is changed to support ARM NT.
Although there is no way to differentiate between ARM (Windows CE) and ARM NT
(Windows on ARM), since LLVM currently only supports Windows on ARM, simply take
/machine:arm to mean Windows on ARM.
llvm-svn: 218105
I made LLD to report an error if /safeseh:no option is given on x64,
but it turned out MSVC link.exe doesn't report error on it.
Removing the check.
llvm-svn: 218077
The entry point file needs to be processed after all other
object files and before all .lib files. It was processed
after .lib files. That caused an issue that the entry point
function was not resolved from the standard library files.
llvm-svn: 213804
On Windows there are four "main" functions -- main, wmain, WinMain,
or wWinMain. Their parameter types are diffferent. The standard
library provides four different entry functions (i.e.
{w,}{WinMain,main}CRTStartup) for them. You need to use the right
entry routine for your "main" function.
If you give an /entry option, the specified name is used
unconditionally.
Otherwise, the linker needs to select the right one based on
user-supplied entry point function. This can be done after the
linker reads all the input files.
This patch moves the code to determine the entry point function
from the driver to a virtual input file. It also implements the
correct logic for the entry point function selection.
llvm-svn: 213713
As written in the comment in this patch, symbol names specified with
/export option is resolved in a special way; for /export:foo, linker
finds a foo@<number> symbol if such symbols exists.
On Windows, a function in stdcall calling convention is mangled with
a leading underscore and following "@" and numbers. This name
mangling is kind of automatic, so you can sometimes omit _ and @number
when specifying a symbol. /export option is that case.
Previously, if a file in an archive file foo.lib provides a symbol
_fn@8, and /export:fn is specified, LLD failed to resolve the symbol.
It only tried to find _fn, and failed to find _fn@8. With this patch,
_fn@8 will be searched on the second iteration.
Differential Revision: http://reviews.llvm.org/D3736
llvm-svn: 208754
We did not actively try to resolve dllexported symbols specified
by /export or by a module definition file. So if exported symbols
would be resolved for other reasons, like other symbols refer to
them, that was fine, but if (unreferenced) exported symbols were
in an archive file, and no one refers to that file in the archive,
they remained unresolved.
That would obviously cause the issue that dllexported symbols are
not in a resultant DLL.
In this patch, we create an undefined symbol for each dllexported
symbol, to let the core linker to resolve it.
llvm-svn: 208452
Linker should create _imp_ symbols for local use only when such
symbols cannot be resolved in any other way. If it overrides real
imported symbols, such symbols remain virtually unresolved without
error, causing odd issues. I observed that a program linked with
LLD entered an infinite loop before reaching main() because of
this issue.
This patch moves the virtual file creating _imp_ symbols to the
very end of the input file list. Previously, the file is at the end
of the library file group. Linker might revisit the group many times,
so it was not really at the end of the input file list.
llvm-svn: 207605
Implicit symbol for local use implemented in r207141 was not fully
compatible with MSVC link.exe. In r207141, I implemented the feature
in such way that implicit symbols are defined only when they are
exported with /EXPORT option.
After that I found that implicit symbols are defined not only for
dllexported symbols but for all defined symbols. Actually _imp_
implicit symbols have no relationship with the dllexport feature. You
could add _imp_ to any symbol to get a pointer to the symbol, whether
the symbol is dllexported or not. It looks pretty weird to me but
that's what we want if link.exe behaves that way.
Here is a bit about the implementation: Creating all implicit symbols
beforehand is going to be a huge waste of resource. This feature is
rarely used, and MSVC link.exe even prints out a warning message when
it finds this feature is being used. So we create implicit symbols
on demand. There is an archive file that creates implicit symbols when
they are needed.
llvm-svn: 207476
Not all symbols are decorated with an underscore in x86. You can
write undecorated symbols in assembly, for example. Thus this
assertion is too strong.
llvm-svn: 207125
Seems getSomething() is more common naming scheme than just a noun
to get something, so renaming these members.
Differential Revision: http://llvm-reviews.chandlerc.com/D3285
llvm-svn: 205589
This patch is to support --defsym option for ELF file format/GNU-compatible
driver. Currently it takes a symbol name followed by '=' and a number. If such
option is given, the driver sets up an absolute symbol with the specified
address. You can specify multiple --defsym options to define multiple symbols.
GNU LD's --defsym provides many more features. For example, it allows users to
specify another symbol name instead of a number to define a symbol alias, or it
even allows a symbol plus an offset (e.g. --defsym=foo+3) to define symbol-
relative alias. This patch does not support that, but will be supported in
subsequent patches.
Differential Revision: http://llvm-reviews.chandlerc.com/D3208
llvm-svn: 205029
If all input files are compatible with Structured Exception Handling, linker
is supposed to create an exectuable with a table for SEH handlers. The table
consists of exception handlers entry point addresses.
The basic idea of SEH in x86 Microsoft ABI is to list all valid entry points
of exception handlers in an read-only memory, so that an attacker cannot
override the addresses in it. In x86 ABI, data for exception handling is mostly
on stack, so it's volnerable to stack overflow attack. In order to protect
against it, Windows runtime uses the table to check a return address, to
ensure that the address is really an valid entry point for an exception handler.
Compiler emits a list of exception handler functions to .sxdata section. It
also emits a marker symbol "@feat.00" to indicate that the object is compatible
with SEH. SEH is a relatively new feature for COFF, and mixing SEH-compatible
and SEH-incompatible objects will result in an invalid executable, so is the
marker.
If all input files are compatible with SEH, LLD emits a SEH table. SEH table
needs to be pointed by Load Configuration strucutre, so when emitting a SEH
table LLD emits it too. The address of a Load Configuration will be stored to
the file header.
llvm-svn: 202248
This restores the debug output to how it was before r197727 broke it. This
went undetected because the corresponding test was never run due to broken
feature detection.
llvm-svn: 202079
Currently LLD always print a warning message if the same symbol is specified
more than once for /export option. It's a bit annoying because specifying the
same symbol with compatible options is actually safe and considered as a
normal use case. This patch makes LLD to warn only when incompatible export
options are given.
llvm-svn: 198104
Each export symbol descriptor has unique name attribute, so std::set is
better container than std::vector for it. No functionality change.
llvm-svn: 198102
Default ordinals were assigned in EdataPass, and the assigned values were
then discarded in the pass. No code other than EdataPass would not be able
to get all of the information about ordinals. That's not ideal since I'm
writing code to emit an Import Library file, which also needs ordinals.
This is a patch to move the code to assign default ordinals from EdataPass
to LinkingContext::verify(), so that assigned ordinals will be available
anywhere.
No functionality change.
llvm-svn: 197797
The main changes are in:
include/lld/Core/Reference.h
include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.
1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers. It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.
The new model is that there is a global Registry object. You programmatically
register the Readers you want with the registry object. Whenever you need to
read/parse a file, you ask the registry to do it, and the registry tries each
registered reader.
For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object.
2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings. Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values. The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value. This tuple system allows conversion to and from strings with
no ambiguities.
llvm-svn: 197727
This is the first patch to emit data for the DLL export table. The DLL export
table is the data used by the Windows loader to find the address of exported
function from DLL. With this patch, LLD is able to emit a valid DLL export
table which the Windows loader can interpret and load.
The data structure of the DLL export table is described in the Microsoft
PE/COFF Specification, section 5.3.
DLL support is not complete yet; the linker needs to emit an import library
for a DLL, otherwise the linker cannot link against the DLL. We also do not
support export-only-by-ordinal yet.
llvm-svn: 197212
/ALTERNATENAME is a rarely-used, undocumented command line option that is
needed to link LLD for release build. It seems that the option is for defining
an weak alias; /alternatename:foo=bar defines weak symbol "foo" for "bar".
If "foo" is defined in an input file, it'll be linked normally and the command
line option will have no effect. If it's not defined, "foo" will be handled
as an alias for "bar".
This patch implements the parser for the option. The actual weak alias handling
will be implemented in a separate patch.
llvm-svn: 196743
