2013-04-05 02:59:24 +08:00
|
|
|
//===- lib/Driver/CoreDriver.cpp ------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Linker
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-01-22 06:54:56 +08:00
|
|
|
#include "lld/Core/Reader.h"
|
2013-04-05 02:59:24 +08:00
|
|
|
#include "lld/Driver/Driver.h"
|
2013-08-07 06:31:59 +08:00
|
|
|
#include "lld/ReaderWriter/CoreLinkingContext.h"
|
2013-04-05 02:59:24 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
|
|
|
#include "llvm/ADT/Triple.h"
|
|
|
|
#include "llvm/Option/Arg.h"
|
|
|
|
#include "llvm/Option/Option.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/FileSystem.h"
|
|
|
|
#include "llvm/Support/Host.h"
|
|
|
|
#include "llvm/Support/ManagedStatic.h"
|
|
|
|
#include "llvm/Support/Path.h"
|
|
|
|
#include "llvm/Support/PrettyStackTrace.h"
|
|
|
|
#include "llvm/Support/Signals.h"
|
2014-10-18 13:33:55 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2013-04-05 02:59:24 +08:00
|
|
|
|
|
|
|
using namespace lld;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
2013-12-25 04:43:54 +08:00
|
|
|
// Create enum with OPT_xxx values for each option in CoreOptions.td
|
2013-09-06 04:21:24 +08:00
|
|
|
enum {
|
2013-04-05 02:59:24 +08:00
|
|
|
OPT_INVALID = 0,
|
2013-08-01 07:17:41 +08:00
|
|
|
#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM, \
|
|
|
|
HELP, META) \
|
2013-04-05 02:59:24 +08:00
|
|
|
OPT_##ID,
|
|
|
|
#include "CoreOptions.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
|
|
|
|
|
|
|
// Create prefix string literals used in CoreOptions.td
|
|
|
|
#define PREFIX(NAME, VALUE) const char *const NAME[] = VALUE;
|
|
|
|
#include "CoreOptions.inc"
|
|
|
|
#undef PREFIX
|
|
|
|
|
|
|
|
// Create table mapping all options defined in CoreOptions.td
|
|
|
|
static const llvm::opt::OptTable::Info infoTable[] = {
|
2013-08-01 07:17:41 +08:00
|
|
|
#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM, \
|
2013-04-05 02:59:24 +08:00
|
|
|
HELPTEXT, METAVAR) \
|
|
|
|
{ PREFIX, NAME, HELPTEXT, METAVAR, OPT_##ID, llvm::opt::Option::KIND##Class, \
|
2013-08-01 07:17:41 +08:00
|
|
|
PARAM, FLAGS, OPT_##GROUP, OPT_##ALIAS, ALIASARGS },
|
2013-04-05 02:59:24 +08:00
|
|
|
#include "CoreOptions.inc"
|
|
|
|
#undef OPTION
|
|
|
|
};
|
|
|
|
|
|
|
|
// Create OptTable class for parsing actual command line arguments
|
|
|
|
class CoreOptTable : public llvm::opt::OptTable {
|
|
|
|
public:
|
2015-10-22 00:31:56 +08:00
|
|
|
CoreOptTable() : OptTable(infoTable) {}
|
2013-04-05 02:59:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace anonymous
|
|
|
|
|
|
|
|
|
|
|
|
namespace lld {
|
|
|
|
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
static const Registry::KindStrings coreKindStrings[] = {
|
2013-12-21 04:34:19 +08:00
|
|
|
{ CoreLinkingContext::TEST_RELOC_CALL32, "call32" },
|
|
|
|
{ CoreLinkingContext::TEST_RELOC_PCREL32, "pcrel32" },
|
|
|
|
{ CoreLinkingContext::TEST_RELOC_GOT_LOAD32, "gotLoad32" },
|
|
|
|
{ CoreLinkingContext::TEST_RELOC_GOT_USE32, "gotUse32" },
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
{ CoreLinkingContext::TEST_RELOC_LEA32_WAS_GOT, "lea32wasGot" },
|
|
|
|
LLD_KIND_STRING_END
|
|
|
|
};
|
|
|
|
|
2015-06-23 06:06:48 +08:00
|
|
|
bool CoreDriver::link(llvm::ArrayRef<const char *> args,
|
|
|
|
raw_ostream &diagnostics) {
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
CoreLinkingContext ctx;
|
2013-12-20 15:48:29 +08:00
|
|
|
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
// Register possible input file parsers.
|
|
|
|
ctx.registry().addSupportYamlFiles();
|
2013-12-20 15:48:29 +08:00
|
|
|
ctx.registry().addKindTable(Reference::KindNamespace::testing,
|
|
|
|
Reference::KindArch::all, coreKindStrings);
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
|
2015-06-21 14:32:10 +08:00
|
|
|
if (!parse(args, ctx))
|
Convert CoreInputGraph.
This is a part of InputGraph cleanup to represent input files as a flat
list of Files (and some meta-nodes for group etc.)
We cannot achieve that goal in one gigantic patch, so I split the task
into small steps as shown below.
(Recap the progress so far: Currently InputGraph contains a list of
InputElements. Each InputElement contain one File (that used to have
multiple Files, but I eliminated that use case in r223867). Files are
currently instantiated in Driver::link(), but I already made a change
to separate file parsing from object instantiation (r224102), so we
can safely instantiate Files when we need them, instead of wrapping
a file with the wrapper class (FileNode class). InputGraph used to
act like a generator class by interpreting groups by itself, but it's
now just a container of a list of InputElements (r223867).)
1. Instantiate Files in the driver and wrap them with WrapperNode.
WrapperNode is a temporary class that allows us to instantiate Files
in the driver while keep using the current InputGraph data structure.
This patch demonstrates how this step 1 looks like, using Core driver
as an example.
2. Do the same thing for the other drivers.
When step 2 is done, an InputGraph consists of GroupEnd objects or
WrapperNodes each of which contains one File. Other types of
FileNode subclasses are removed.
3. Replace InputGraph with std::vector<std::unique_ptr<InputElement>>.
InputGraph is already just a container of list of InputElements,
so this step removes that needless class.
4. Remove WrapperNode.
We need some code cleanup between each step, because many classes
do a bit odd things (e.g. InputGraph::getGroupSize()). I'll straight
things up as I need to.
llvm-svn: 225313
2015-01-07 07:06:49 +08:00
|
|
|
return false;
|
[lld] Introduce registry and Reference kind tuple
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
2013-12-20 05:58:00 +08:00
|
|
|
return Driver::link(ctx);
|
2013-04-05 02:59:24 +08:00
|
|
|
}
|
|
|
|
|
2015-06-23 06:06:48 +08:00
|
|
|
bool CoreDriver::parse(llvm::ArrayRef<const char *> args,
|
|
|
|
CoreLinkingContext &ctx, raw_ostream &diagnostics) {
|
2013-04-05 02:59:24 +08:00
|
|
|
// Parse command line options using CoreOptions.td
|
|
|
|
CoreOptTable table;
|
|
|
|
unsigned missingIndex;
|
|
|
|
unsigned missingCount;
|
2015-06-23 06:06:52 +08:00
|
|
|
llvm::opt::InputArgList parsedArgs =
|
|
|
|
table.ParseArgs(args.slice(1), missingIndex, missingCount);
|
2013-04-05 02:59:24 +08:00
|
|
|
if (missingCount) {
|
2013-08-22 06:57:10 +08:00
|
|
|
diagnostics << "error: missing arg value for '"
|
2015-06-23 06:06:52 +08:00
|
|
|
<< parsedArgs.getArgString(missingIndex) << "' expected "
|
2013-08-22 06:57:10 +08:00
|
|
|
<< missingCount << " argument(s).\n";
|
2013-09-25 07:26:34 +08:00
|
|
|
return false;
|
2013-04-05 02:59:24 +08:00
|
|
|
}
|
|
|
|
|
2013-08-22 06:57:10 +08:00
|
|
|
// Set default options
|
|
|
|
ctx.setOutputPath("-");
|
|
|
|
ctx.setDeadStripping(false);
|
|
|
|
ctx.setGlobalsAreDeadStripRoots(false);
|
|
|
|
ctx.setPrintRemainingUndefines(false);
|
|
|
|
ctx.setAllowRemainingUndefines(true);
|
|
|
|
ctx.setSearchArchivesToOverrideTentativeDefinitions(false);
|
|
|
|
|
2015-01-18 06:38:09 +08:00
|
|
|
// Process all the arguments and create input files.
|
2015-06-23 06:06:52 +08:00
|
|
|
for (auto inputArg : parsedArgs) {
|
2013-08-22 06:57:10 +08:00
|
|
|
switch (inputArg->getOption().getID()) {
|
|
|
|
case OPT_mllvm:
|
|
|
|
ctx.appendLLVMOption(inputArg->getValue());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_entry:
|
|
|
|
ctx.setEntrySymbolName(inputArg->getValue());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_output:
|
|
|
|
ctx.setOutputPath(inputArg->getValue());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_dead_strip:
|
|
|
|
ctx.setDeadStripping(true);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_keep_globals:
|
|
|
|
ctx.setGlobalsAreDeadStripRoots(true);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_undefines_are_errors:
|
|
|
|
ctx.setPrintRemainingUndefines(true);
|
|
|
|
ctx.setAllowRemainingUndefines(false);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_commons_search_archives:
|
|
|
|
ctx.setSearchArchivesToOverrideTentativeDefinitions(true);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case OPT_add_pass:
|
|
|
|
ctx.addPassNamed(inputArg->getValue());
|
|
|
|
break;
|
|
|
|
|
Convert CoreInputGraph.
This is a part of InputGraph cleanup to represent input files as a flat
list of Files (and some meta-nodes for group etc.)
We cannot achieve that goal in one gigantic patch, so I split the task
into small steps as shown below.
(Recap the progress so far: Currently InputGraph contains a list of
InputElements. Each InputElement contain one File (that used to have
multiple Files, but I eliminated that use case in r223867). Files are
currently instantiated in Driver::link(), but I already made a change
to separate file parsing from object instantiation (r224102), so we
can safely instantiate Files when we need them, instead of wrapping
a file with the wrapper class (FileNode class). InputGraph used to
act like a generator class by interpreting groups by itself, but it's
now just a container of a list of InputElements (r223867).)
1. Instantiate Files in the driver and wrap them with WrapperNode.
WrapperNode is a temporary class that allows us to instantiate Files
in the driver while keep using the current InputGraph data structure.
This patch demonstrates how this step 1 looks like, using Core driver
as an example.
2. Do the same thing for the other drivers.
When step 2 is done, an InputGraph consists of GroupEnd objects or
WrapperNodes each of which contains one File. Other types of
FileNode subclasses are removed.
3. Replace InputGraph with std::vector<std::unique_ptr<InputElement>>.
InputGraph is already just a container of list of InputElements,
so this step removes that needless class.
4. Remove WrapperNode.
We need some code cleanup between each step, because many classes
do a bit odd things (e.g. InputGraph::getGroupSize()). I'll straight
things up as I need to.
llvm-svn: 225313
2015-01-07 07:06:49 +08:00
|
|
|
case OPT_INPUT: {
|
|
|
|
std::vector<std::unique_ptr<File>> files
|
2015-01-15 12:34:31 +08:00
|
|
|
= loadFile(ctx, inputArg->getValue(), false);
|
2015-01-16 07:15:09 +08:00
|
|
|
for (std::unique_ptr<File> &file : files)
|
|
|
|
ctx.getNodes().push_back(llvm::make_unique<FileNode>(std::move(file)));
|
2013-09-03 09:25:21 +08:00
|
|
|
break;
|
Convert CoreInputGraph.
This is a part of InputGraph cleanup to represent input files as a flat
list of Files (and some meta-nodes for group etc.)
We cannot achieve that goal in one gigantic patch, so I split the task
into small steps as shown below.
(Recap the progress so far: Currently InputGraph contains a list of
InputElements. Each InputElement contain one File (that used to have
multiple Files, but I eliminated that use case in r223867). Files are
currently instantiated in Driver::link(), but I already made a change
to separate file parsing from object instantiation (r224102), so we
can safely instantiate Files when we need them, instead of wrapping
a file with the wrapper class (FileNode class). InputGraph used to
act like a generator class by interpreting groups by itself, but it's
now just a container of a list of InputElements (r223867).)
1. Instantiate Files in the driver and wrap them with WrapperNode.
WrapperNode is a temporary class that allows us to instantiate Files
in the driver while keep using the current InputGraph data structure.
This patch demonstrates how this step 1 looks like, using Core driver
as an example.
2. Do the same thing for the other drivers.
When step 2 is done, an InputGraph consists of GroupEnd objects or
WrapperNodes each of which contains one File. Other types of
FileNode subclasses are removed.
3. Replace InputGraph with std::vector<std::unique_ptr<InputElement>>.
InputGraph is already just a container of list of InputElements,
so this step removes that needless class.
4. Remove WrapperNode.
We need some code cleanup between each step, because many classes
do a bit odd things (e.g. InputGraph::getGroupSize()). I'll straight
things up as I need to.
llvm-svn: 225313
2015-01-07 07:06:49 +08:00
|
|
|
}
|
2013-08-22 06:57:10 +08:00
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2013-04-05 02:59:24 +08:00
|
|
|
}
|
|
|
|
|
2015-12-17 04:53:27 +08:00
|
|
|
parseLLVMOptions(ctx);
|
|
|
|
|
2015-01-15 16:46:36 +08:00
|
|
|
if (ctx.getNodes().empty()) {
|
2013-08-22 06:57:10 +08:00
|
|
|
diagnostics << "No input files\n";
|
2013-09-25 07:26:34 +08:00
|
|
|
return false;
|
2013-04-05 02:59:24 +08:00
|
|
|
}
|
|
|
|
|
2013-08-22 06:57:10 +08:00
|
|
|
// Validate the combination of options used.
|
|
|
|
return ctx.validate(diagnostics);
|
2013-04-05 02:59:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace lld
|