Export definitions in a module definition file is as follows:
exportedname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]
Previously we did not support =internalname, so users couldn't export
symbols from a DLL with a different name.
llvm-svn: 207827
In general the linker scripts's GROUP command works like a pair
of command line options --start-group/--end-group. But there is
a difference in the files look up algorithm.
The --start-group/--end-group commands use a trivial approach:
a) If the path has '-l' prefix, add 'lib' prefix and '.a'/'.so'
suffix and search the path through library search directories.
b) Otherwise, use the path 'as-is'.
The GROUP command implements more compicated approach:
a) If the path has '-l' prefix, add 'lib' prefix and '.a'/'.so'
suffix and search the path through library search directories.
b) If the path does not have '-l' prefix, and sysroot is configured,
and the path starts with the / character, and the script being
processed is located inside the sysroot, search the path under
the sysroot. Otherwise, try to open the path in the current
directory. If it is not found, search through library search
directories.
https://www.sourceware.org/binutils/docs-2.24/ld/File-Commands.html
The patch reviewed by Shankar Easwaran, Rui Ueyama.
llvm-svn: 207769
When creating a .lib file, we should strip the leading underscore,
but should not strip stdcall atsign suffix. Otherwise produced .lib
files cannot be linked.
llvm-svn: 207729
Previously the input file for the lib.exe command would be removed
as soon as the command exits, so we couldn't write a test to check
the file contents are correct.
This patch adds /lldmoduledeffile: option to retain a copy of the
temporary file at the given file path, so that you can see the file
if you want.
llvm-svn: 207727
I'm a bit surprised that I have not implemented this yet. This is
definitely needed to handle real-world module definition files.
This patch contains a unit test for r207294.
llvm-svn: 207297
LIBRARY directive in a module definition file specifies the output
DLL file name. It also takes an optional value for the base address.
llvm-svn: 206647
Currently LLD supports --defsym only in the form of
--defsym=<symbol>=<integer>, where the integer is interpreted as the
absolute address of the symbol. This patch extends it to allow other
symbol name to be given as an RHS value. If a RHS value is a symbol
name, the LHS symbol will be defined as an alias for the RHS symbol.
Internally, a LHS symbol is represented as a zero-size defined atom
who has an LayoutAfter reference to an undefined atom, whose name is
the RHS value. Everything else is already implemented -- Resolver
will resolve the undefined symbol, and the layout pass will layout
the two atoms at the same location. Looks like it's working fine.
Note that GNU LD supports --defsym=<symbol>=<symbol>+<addend>. That
feature is out of scope of this patch.
Differential Revision: http://reviews.llvm.org/D3332
llvm-svn: 206417
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
ELFLinkingContext has a method addUndefinedAtomsFromSharedLibrary().
The method is being used to skip a shared library within --start-group
and --end-group if it's not the first iteration of the group.
We have the same, incomplete mechanism to skip a shared library within
a group too. That's implemented in ELFFileNode. It's intended to not
return a shared library on the second or further iterations in the
first place. This mechanism is preferred over
addUndefinedAtomsFromSharedLibrary because the policy is implemented
in Input Graph -- that's what Input Graph is for.
This patch removes the dupluicate feature and fixes ELFFileNode.
Differential Revision: http://llvm-reviews.chandlerc.com/D3280
llvm-svn: 205566
"x.empty()" is more idiomatic than "x.size() == 0". This patch is to
add such method and use it in LLD.
Differential Revision: http://llvm-reviews.chandlerc.com/D3279
llvm-svn: 205558
Seems clang-modernize couldn't add "override" to nested classes, so
doing it by hand. Also removed unused virtual member function that
is not overriding anything, that seems to have been added by mistake.
llvm-svn: 205552
An ordinal is set to each child of Input Graph, but no one actually
uses it. The only piece of code that gets ordinaly values is
sortInputElements in InputGraph.cpp, but it does not actually do
anything -- we assign ordinals in increasing order just before
calling sort, so when sort is called it's already sorted. It's no-op.
We can simply remove it. No functionality change.
Differential Revision: http://llvm-reviews.chandlerc.com/D3270
llvm-svn: 205501
Resolver is sending too much information to Input Graph than Input
Graph actually needs. In order to collect the detailed information,
which wouldn't be consumed by anyone, we have a good amount of code
in Resolver, Input Graph and Input Elements. This patch is to
simplify it. No functionality change.
Specifically, this patch replaces ResolverState enum with a boolean
value. The enum defines many bits to notify the progress about
linking to Input Graph using bit masks, however, what Input Graph
actually does is to compare a given value with 0. The details of
the bit mask is simply being ignored, so the efforts to collect
such data is wasted.
This patch also changes the name of the notification interface from
setResolverState to notifyProgress, to make it sounds more like
message passing style. It's not a setter but something to notify of
an update, so the new name should be more appropriate than before.
Differential Revision: http://llvm-reviews.chandlerc.com/D3267
llvm-svn: 205463
LinkingContext and InputGraph are unnecessarily entangled. Most linker
input file data, e.g. the vector containing input files, the next index
of the input file, etc. are managed by InputGraph, but only the current
input file is for no obvious reason managed by LinkingContext.
This patch is to move code from LinkingContext to InputGraph to fix it.
It's now clear who's reponsible for managing input file state, which is
InputGraph, and LinkingContext is now free from that responsibility.
It improves the readability as we now have fewer dependencies between
classes. No functionality change.
Differential Revision: http://llvm-reviews.chandlerc.com/D3259
llvm-svn: 205394
insertElementAt()'s third parameter is not only unused but also ignored
if you pass Position::END. The actual meaning of the parameter was obscure.
Differential Revision: http://llvm-reviews.chandlerc.com/D3256
llvm-svn: 205376
Group class is designed for GNU LD's --start-group and --end-group. There's
no obvious need to have two classes for it -- one as an abstract base class
and the other as a concrete class.
llvm-svn: 205375
InputGraph has too many knobs and controls that are not being used. This
patch is to remove dead code, unused features and a class. There are two
things that worth noting, besides simple dead code removal:
1. ControlNode class is removed. We had it as the base class of Group
class, but it provides no functionality particularly meaningful. We now
have shallower class hierarchy that is easier to understand.
2. InputGraph provides a feature to replace a node with its internal data.
It is being used to "expand" some type of node, such as a Linker Script
node, with its actual files. We used to have two options when replacing
it -- ExpandOnly or ExpandAndReplace. ExpandOnly was to expand it but not
remove the node from the tree. There is no use of that option in the code,
so it was a dead feature.
Differential Revision: http://llvm-reviews.chandlerc.com/D3252
llvm-svn: 205363
PECOFFFileNode::parse can be called twice -- once by WinLink driver and
once more by Driver. We want to make sure that the second call won't mess
up the internal data.
llvm-svn: 205284
Some Clang build uses .imp not .lib file extension for an import library file,
so we need to treat such file as a library file.
Ideally we should not rely on file extensions to detect file type. Instead
we should use magic bytes at beginning of a file. The GNU-compatible driver
actually does that but it made writing unit tests hard, so I chose an ad-hoc
approach for now.
llvm-svn: 205283
.gnu.linkonce sections are similar to section groups.
They were supported before section groups existed and provided a way
to resolve COMDAT sections using a different design.
There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant in a binary.
.gnu.linkonce based symbol resolution achieves that.
Review : http://llvm-reviews.chandlerc.com/D3242
llvm-svn: 205280
This reverts commit 5d5ca72a7876c3dd3dd1db83dc6a0d74be9e2cd1.
Discuss on a better design to raise error when there is a similar group with Gnu
linkonce sections and COMDAT sections.
llvm-svn: 205224
.gnu.linkonce sections are similar to section groups. They were supported before
section groups existed and provided a way to resolve COMDAT sections using a
different design. There are few implementations that use .gnu.linkonce sections
to store simple floating point constants which doesnot require complex section
group support but need a way to store only one copy of the floating point
constant. .gnu.linkonce based symbol resolution achieves that.
llvm-svn: 205163
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 --allow-multiple-definition option is given, LLD does not treat duplicate
symbol error as a fatal error. GNU LD supports this option.
Differential Revision: http://llvm-reviews.chandlerc.com/D3211
llvm-svn: 205015
Currently we use both layout-after and layout-before edges to specify atom
orders in the resulting executable. We have a complex piece of code in
LayoutPass.cpp to deal with both types of layout specifiers.
(In the following description, I denote "Atom A having a layout-after edge
to B" as "A -> B", and A's layout-before to B as "A => B".)
However, that complexity is not really needed for this reason: If there
are atoms such that A => B, B -> A is always satisifed, so using only layout-
after relationships will yield the same result as the current code.
Actually we have a piece of complex code that verifies that, for each A -> B,
B => [ X => Y => ... => Z => ] A is satsified, where X, Y, ... Z are all
zero-size atoms. We can get rid of the code from our codebase because layout-
before is basically redundant.
I think we can simplify the code for layout-after even more than this, but
I want to just remove this pass for now for simplicity.
Layout-before edges are still there for dead-stripping, so this change won't
break it. We will remove layout-before in a followup patch once we fix the
dead-stripping pass.
Differential Revision: http://llvm-reviews.chandlerc.com/D3164
llvm-svn: 204966
Use <mutex> instead of "llvm/Support/Mutex.h".
Also change the type of mutex for the context object to recursive mutex, as
the driver could acquire the lock recursively. E.g. If file A has .drectve
section containing /defaultlib:B, the driver tries to parse file B, and if
file B has .drectve section, the driver acquires the lock again.
llvm-svn: 204850
InputElement::parse() may recursively call WinLinkDriver::parse() to handle
.drectve section contents, and if /defaultlib option exists in the section,
the driver will mutate the input graph to add a new input file to the graph.
So the access to input graph needs to be protected with mutext.
llvm-svn: 204285
COMDAT_SELECT_LARGEST is a COMDAT type that make linker to choose the largest
definition from among all of the definition of a symbol. If the size is the
same, the choice is arbitrary.
Differential Revision: http://llvm-reviews.chandlerc.com/D3011
llvm-svn: 204172
If the driver finds a command line option in the form of "@filename", the
option will be replaced with the content of the given file. It's an error
if a response file cannot be read.
llvm-svn: 203875
This results in some simplifications to the code where an OwningPtr had to
be used with the previous api and then ownership moved to a unique_ptr for
the rest of lld.
llvm-svn: 203809
MergeCases table should not have an entry for MergeContents because atoms with
MergeContents attribute should never have name. This issue was not caught by a
test because getting a value of 6th element of an array of array actually gets
the first element's value of the next array, and that happened to be a valid
value. Added asserts to catch that error.
llvm-svn: 203322
Summary:
COMDAT_SELECT_SAME_SIZE is a COMDAT type that I presume exist only in COFF.
The semantics of the type is that linker should merge such COMDAT sections if
their sizes are the same. Otherwise it's an error.
Reviewers: Bigcheese, shankarke, kledzik
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2996
llvm-svn: 203308
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
Syntactically /SAFESEH is a boolean flag -- you can pass /SAFESEH or /SAFESEH:no.
The meaning of /SAFESEH is as follows.
- If /SAFESEH is specified, the linker will produce an executable with SEH table.
If any input files are not compatible with SEH, it's an error.
- If /SAFESEH:no is specified, the linker will not emit SEH table even if all
input files are compatible with SEH.
- If no option is specified, the linker emits SEH table if all input files are
compatible with SEH.
llvm-svn: 201895
Add new virtual virtual function `isRelaOutputFormat` to the
`ELFLinkingContext` class. Call this function everywhere we need to
select a relocation table format.
Patch reviewed by Shankar Easwaran and Rui Ueyama.
llvm-svn: 199973
Refactor the parser so that the parser can return arbitrary type of parse
result other than a vector of ExportDesc. Parsers for non-EXPORTS directives
will be implemented in different patches. No functionality change.
llvm-svn: 198993
The main goal of this patch is to allow "mach-o encoded as yaml" and "native
encoded as yaml" documents to be intermixed. They are distinguished via
yaml tags at the start of the document. This will enable all mach-o test cases
to be written using yaml instead of checking in object files.
The Registry was extend to allow yaml tag handlers to be registered. The
mach-o Reader adds a yaml tag handler for the tag "!mach-o".
Additionally, this patch fixes some buffer ownership issues. When parsing
mach-o binaries, the mach-o atoms can have pointers back into the memory
mapped .o file. But with yaml encoded mach-o, name and content are ephemeral,
so a copyRefs parameter was added to cause the mach-o atoms to make their
own copy.
llvm-svn: 198986
Module-definition (.def) files are the file containing linker directives,
such as export symbols. Because link.exe supports the same features as command
line options, just as some Linker Script commands overlaps with command line
options, use of module-definition file is not really necessary. It provides
an alternative way to specify some linker options.
This patch implements EXPORTS directive. Other directives will be implemented
in the future.
llvm-svn: 198925
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
It will configure resonable defaults for other settings in the
MachOLinkingContext object based on the parameters.
Patch by Joe Ranieri
llvm-svn: 197851
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
/DLLEXPORT is a command line option to export a symbol. __declspec(dllexport)
uses that to make the linker to export DLLExport'ed functions, by adding the
option to .drectve section.
This patch implements the parser of the command line option.
llvm-svn: 197122
This patch is to basically move the functionality to construct Data Directory
from IdataPass to WriterPECOFF.
Data Directory is a part of the PE/COFF header and contains the addresses of
the import tables.
We used to represent the link from Data Directory to the import tables as
relocation references. The idea behind it is that, because relocation
references are processed by the Writer, we wouldn't have to do anything special
to fill the addresses of the import tables. I thought that the addresses would
be set "automatically".
But it turned out that that design made the pass and the writer rather
complicated. In order to make relocation references between Data Directory to
the import tables, these data structures needed to be represented as Atom.
However, because Data Directory is not a section content but a part of the
PE/COFF header, it did not fit well as an Atom. So we ended up having
complicated code both in IdataPass and the writer.
This patch simplifies it.
One side effect of this patch is that we now have ".idata.a", ".idata.d" and
"idata.t" sections for the import address table, the import directory table,
and the import lookup table. The writer looks for the sections by name to find
the start addresses of the sections. We probably should have a better way to
find a specific atom from the core linking result, but currently using the
section name seems to be the easiest way to do that. The Windows loader do not
care about the import table's section layout.
llvm-svn: 197016
/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
Because compare() and its heper functions no longer have to be members of
LayoutPass class, we can remove it from the class. No functionality change.
llvm-svn: 196715
The comparator used in the layout pass has many calls of map::find(). Because
std::sort runs the comparator N*log2(N) times, the maps are looked up with the
same key again and again. The map lookup is not a very fast operation. It made
the pass slow.
This patch eliminates the duplicate map lookups using decorate-sort-undecorate
idiom. The pass used to take 1.1 seconds when linking LLD with LLD on Windows,
but it now takes only 0.3 seconds. Overall performance gain in that case is from
6.1 seconds to 5.2 seconds.
Differential Revision: http://llvm-reviews.chandlerc.com/D2358
llvm-svn: 196714
Currently we do not de-duplicate library files specified by /defaultlib option.
As a result, the same files are added multiple times to the input graph. In
particular, some popular files, such as kernel32.lib or oldnames.lib, are added
more than 10 times during linking of LLD. That makes the linker slower, as it
needs to parse the same file again and again.
This patch solves the issue by de-duplicating. The same file will be added only
once to the input graph. This patch improved the LLD linking time from 10.5
seconds to 7.7 seconds on my 4-core Core i7 Macbook Pro.
llvm-svn: 196504
/MERGE option is a bit complicated for many reasons. Firstly, it takes both
positive and negative arguments. That means we have to have one of three
distinctive values (set, clear or unchange) for each permission bit. In this
patch we represent the three values using two bitmasks.
Secondly, the permissions specified by the parameter is bitwise or-ed with the
default permissions of a section. There is an exception for that rule; if one
of READ, WRITE or EXECUTE bit is specified, unspecified bits need to be
cleared. (So if you specify only WRITE for example, the resulting section will
not have WRITE nor EXECUTE bits.)
Lastly, multiple /merge options are allowed.
llvm-svn: 195882
Looks like -L paths are not positional. They need to be added to a list of
search paths and those needs to be searched when lld looks for a library.
llvm-svn: 195594
This adds LinkerScript support by creating a type Script which is of type
FileNode in the InputGraph. Once the LinkerScript Parser converts the
LinkerScript into a sequence of command, the commands are handled by the
equivalent LinkerScript node for the current Flavor/Target. For ELF, a
ELFGNULdScript gets created which converts the commands to ELF nodes and ELF
control nodes(ELFGroup for handling Group nodes).
Since the Inputfile type has to be determined in the Driver, the Driver needs
to determine the complete path of the file that needs to be processed by the
Linker. Due to this, few tests have been removed since the Driver uses paths
that doesnot exist.
llvm-svn: 195583
Hidden nodes could be a result of expansion, where a flavor might decide to keep
the node that we want to expand but discard it from being processed by the
resolver.
Verifies with unittests.
llvm-svn: 195516
Flavors may like to expand InputGraph nodes, when a filenode after parsing
results in more elements. One such example is while parsing GNU linker scripts.
The linker scripts after parsing would result in a lot of filenodes and probably
controlnodes too.
Adds unittests to verify functionality.
llvm-svn: 195515
This adds functionality to limit shared library undefined atoms to be added
only once by the Resolver.
Dynamic libraries may be processed more than once if they exist within a
Group.
Also adds a test to verify the change.
llvm-svn: 195307
Rui Ueyama