Previously only the toplevel elements were expanded by expandElements().
Now we recursively call getReplacements() to expand input elements even
if they are in, say, in a group.
llvm-svn: 208144
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
Atoms with deadStripNever attribute has already been added to the
dead strip root set at end of Resolver::doDefinedAtom, so no need
to check it for each atom again.
Differential Revision: http://llvm-reviews.chandlerc.com/D3282
llvm-svn: 205575
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
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
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
.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
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
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
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.
target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,
- libclang.so has sufficient libclang*.a(s).
- c-index-test requires just only libclang.so.
FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.
llvm-svn: 202241
There was a bug that the linker does not report an error if symbols specified
by -u (or /include on Windows) are not resolved. This patch fixes it by adding
such symbols to the dead strip root.
llvm-svn: 198041
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 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
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
The fallback atom was used only when it's searching for a symbol in a library;
if an undefined symbol was not found in a library, the LLD looked for its
fallback symbol in the library.
Although it worked in most cases, because symbols with fallbacks usually occur
only in OLDNAMES.LIB (a standard library), that behavior was incompatible with
link.exe. This patch fixes the issue so that the semantics is the same as
MSVC's link.exe
The new (and correct, I believe) behavior is this:
- If there's no definition for an undefined atom, replace the undefined atom
with its fallback and then proceed (e.g. look in the next file or stop
linking as usual.)
Weak External symbols are underspecified in the Microsoft PE/COFF spec. However,
as long as I observed the behavior of link.exe, this seems to be what we want
for compatibility.
Differential Revision: http://llvm-reviews.chandlerc.com/D2162
llvm-svn: 195269
We can add multiple undefined atoms having the same name to the symbol table.
If such atoms are added, the symbol table compares their canBeNull attributes,
and select one having a stronger constraint. If their canBeNulls are the same,
the choice is arbitrary. Currently it choose the existing one.
This patch changes the preference, so that the symbol table choose the new one
if the new atom has a greater canBeNull or a fallback atom. This shouldn't
change the behavior except the case described below.
A new undefined atom may have a new fallback atom attribute. By choosing the new
atom, we can update the fallback atom during Core Linking. PE/COFF actually need
that. For example, _lseek is an alias for __lseek on Windows. One of an object
file in OLDNAMES.LIB has an undefined atom for _lseek with the fallback to
__lseek. When the linker tries to resolve _read, it supposed to read the file
from OLDNAMES.LIB and use the new fallback from the file. Currently LLD cannot
handle such case because duplicate undefined atoms with the same attributes are
ignored.
Differential Revision: http://llvm-reviews.chandlerc.com/D2161
llvm-svn: 194777
Enable this for the following flavors
a) core
b) gnu
c) darwin
Its disabled for the flavor PECOFF. Convenient markers are added with FIXME
comments in the Driver that would be removed and code removed from each flavor.
llvm-svn: 193585
Disable tests to be run with REQUIRES: disable. Note disable is not added to the
config by the test runner Mkaefiles, so essentially disables the test.
Code changes would be required to fix these tests :-
test/darwin/hello-world.objtxt
test/elf/check.test
test/elf/phdr.test
test/elf/ppc.test
test/elf/undef-from-main-dso.test
test/elf/X86_64/note-sections-ro_plus_rw.test
test/pecoff/alignment.test
test/pecoff/base-reloc.test
test/pecoff/bss-section.test
test/pecoff/drectve.test
test/pecoff/dynamic.test
test/pecoff/dynamicbase.test
test/pecoff/entry.test
test/pecoff/hello.test
test/pecoff/imagebase.test
test/pecoff/importlib.test
test/pecoff/lib.test
test/pecoff/multi.test
test/pecoff/reloc.test
test/pecoff/weak-external.test
llvm-svn: 193300
Dead-strip root symbols can be undefined atoms, but should not really be
nonexistent, because dead-strip root symbols should be added to initial
undefined atoms at startup. Whenever you look up its name in the symbol
table, some type of atom will always exist.
llvm-svn: 192831
Rui Ueyama