Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.

I think we don't have to transfer ownership just to free all
instance at once on exit.

In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.

Differential Revision: https://reviews.llvm.org/D24493

llvm-svn: 281425

Implemented by building an ELF file in memory.

elf, default, and binary match gold behavior.

Differential Revision: https://reviews.llvm.org/D24060

llvm-svn: 281108

This flag is implemented similarly to --reproduce in the ELF linker.

This patch implements /linkrepro by moving the cpio writer and associated
utility functions to lldCore, and using that implementation in both linkers.

One COFF-specific detail is that we store the object file from which the
resource files were created in our reproducer, rather than the resource
files themselves. This allows the reproducer to be used on non-Windows
systems for example.

Differential Revision: https://reviews.llvm.org/D22418

llvm-svn: 276719

Differential Revision: http://reviews.llvm.org/D21008

llvm-svn: 271901

This code separates the code to create cpio archive from the driver.

llvm-svn: 269593

If you specify the option in the form of --build-id=0x<hexstring>,
that hexstring is set as a build ID. We observed that the feature
is actually in use in some builds, so we want this feature.

llvm-svn: 269495

We want --reproduce to

* not rewrite scripts and thin archives
* work with absolute paths

Given that, it pretty much has to create a full directory tree. On windows that
is problematic because of the very short maximum path limit. On most cases
users can still work around it with "--repro c:\r", but that is annoying and
not viable for automated testing.

We then need to produce some form of archive with the files. The first option
that comes to mind is .a files since we already have code for writing them.
There are a few problems with them

The format has a dedicated string table, so we cannot start writing it until
all members are known.
Regular implementations don't support creating directories. We could make
llvm-ar support that, but that is probably not a good idea.
The next natural option would be tar. The problem is that to support long path
names (which is how this started) it needs a "pax extended header" making this
an annoying format to write.

The next option I looked at seems a natural fit: cpio files.

They are available on pretty much every unix, support directories and long path
names and are really easy to write. The only slightly annoying part is a
terminator, but at least gnu cpio only prints a warning if it is missing, which
is handy for crashes. This patch still makes an effort to always create it.

llvm-svn: 268404

Previuosly, only files appeared on the command line were copied.

llvm-svn: 268171

The aim of this patch is to make it easy to re-run the command without
updating paths in the command line. Here is a use case.

Assume that Alice is having an issue with lld and is reporting the issue
to developer Bob. Alice's current directly is /home/alice/work and her
command line is "ld.lld -o foo foo.o ../bar.o". She adds "--reproduce repro"
to the command line and re-run. Then the following text will be produced as
response.txt (notice that the paths are rewritten so that they are
relative to /home/alice/work/repro.)

  -o home/alice/work/foo home/alice/work/foo.o home/alice/bar.o

The command also produces the following files by copying inputs.

  /home/alice/repro/home/alice/work/foo.o
  /home/alice/repro/home/alice/bar.o

Alice zips the directory and send it to Bob. Bob get an archive from Alice
and extract it to his home directory as /home/bob/repro. Now his directory
have the following files.

  /home/bob/repro/response.txt
  /home/bob/repro/home/alice/work/foo.o
  /home/bob/repro/home/alice/bar.o

Bob then re-run the command with these files by the following commands.

  cd /home/bob/repro
  ld.lld @response.txt

This command will run the linker with the same command line options and
the same input files as Alice's, so it is very likely that Bob will see
the same issue as Alice saw.

Differential Revision: http://reviews.llvm.org/D19737

llvm-svn: 268169

Using multiple context used to be a really big memory saving because we
could free memory from each file while the linker proceeded with the
symbol resolution. We are getting lazier about reading data from the
bitcode, so I was curious if this was still a good tradeoff.

One thing that is a bit annoying is that we still have to copy the
symbol names. The problem is that the names are stored in the Module and
get freed when we move the module bits during linking.

Long term I think the solution is to add a symbol table to the bitcode.
That way IRObject file will not need to use a Module or a Context and we
can drop it while still keeping a StringRef to the names.

This patch is still be an interesting medium term improvement.

When linking llvm-as without debug info this patch is a small speedup:

master: 29.861877513 seconds
patch: 29.814533787 seconds

With debug info the numbers are

master: 34.765181469 seconds
patch: 34.563351584 seconds

The peak memory usage when linking llvm-as with debug info was

master: 599.10MB
patch: 600.13MB
llvm-svn: 267921

llvm-svn: 267602

This patch only implements support for version scripts of the form:
  { [ global: symbol1; symbol2; [...]; symbolN; ] local: *; };
No wildcards are supported, other than for the local entry. Symbol versioning
is also not supported.

It works by introducing a new Symbol flag which tracks whether a symbol
appears in the global section of a version script.

This patch also simplifies the logic in SymbolBody::isPreemptible(), and
teaches it to handle the case where symbols with default visibility in DSOs
do not appear in the dynamic symbol table because of a version script.

Fixes PR27482.

Differential Revision: http://reviews.llvm.org/D19430

llvm-svn: 267208

llvm-svn: 266231

This patch implements the --dynamic-list option, which adds a list of
global symbol that either should not be bounded by default definition
when creating shared libraries, or add in dynamic symbol table in the
case of creating executables.

The patch modifies the ScriptParserBase class to use a list of Token
instead of StringRef, which contains information if the token is a
quoted or unquoted strings. It is used to use a faster search for
exact match symbol name.

The input file follow a similar format of linker script with some
simplifications (it does not have scope or node names). It leads
to a simplified parser define in DynamicList.{cpp,h}.

Different from ld/gold neither glob pattern nor mangled names
(extern 'C++') are currently supported.

llvm-svn: 266227

start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.

In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.

http://reviews.llvm.org/D18814

llvm-svn: 265710

Differential Revision: http://reviews.llvm.org/D18669

llvm-svn: 265073

Fixes pr26908. This patch is based on Filipe Cabecinhas'
patch (http://reviews.llvm.org/D18167)

http://reviews.llvm.org/D18169

llvm-svn: 263569

Now that DarwinLdDriver is the only derived class of Driver.
This patch merges them and actually removed the class because
they can now just be non-member functions. This change simplifies
a common header, Driver.h.

http://reviews.llvm.org/D17788

llvm-svn: 262502

llvm-svn: 262168

llvm-svn: 262167

llvm-svn: 262159

llvm-svn: 260598

http://reviews.llvm.org/D16668

llvm-svn: 259597

This reverts r259395 which reverted r259143.

llvm-svn: 259572

llvm-svn: 259395

This patch let the driver keep going until it parses all
command line options.

http://reviews.llvm.org/D16645

llvm-svn: 259143

In many situations, we don't want to exit at the first error even in the
process model. For example, it is better to report all undefined symbols
rather than reporting the first one that the linker picked up randomly.

In order to handle such errors, we don't need to wrap everything with
ErrorOr (thanks for David Blaikie for pointing this out!) Instead, we
can set a flag to record the fact that we found an error and keep it
going until it reaches a reasonable checkpoint.

This idea should be applicable to other places. For example, we can
ignore broken relocations and check for errors after visiting all relocs.

In this patch, I rename error to fatal, and introduce another version of
error which doesn't call exit. That function instead sets HasError to true.
Once HasError becomes true, it stays true, so that we know that there
was an error if it is true.

I think introducing a non-noreturn error reporting function is by itself
a good idea, and it looks to me that this also provides a gradual path
towards lld-as-a-library (or at least embed-lld-to-your-program) without
sacrificing code readability with lots of ErrorOr's.

http://reviews.llvm.org/D16641

llvm-svn: 259069

llvm-svn: 257078

createFiles was doing more than creating files despite its name.
Now these things are moved to a new function.

llvm-svn: 257077

Previously, we handle archive files with --whole-archive this way:
create instances of ArchiveFile, call getMembers to obtain memory
buffers of archive members, and create ObjectFiles for the members.
We didn't call anything except getMembers if --whole-archive was
specified.

I noticed that we didn't actually have to create ArchiveFile instaces
at all for that case. All we need is to get a list of memory buffers
for members, which can be done by a non-member function.

This patch removes getMembers member function from ArchiveFile.
Also removed unnecessary code for memory management.

llvm-svn: 256893

Now that the SymbolTable is templated, we don't need the ELFData class or
multiple inheritance.

llvm-svn: 250005

ArgParser was a class with only one member function, so it didn't
have to be a class.

llvm-svn: 249988

In the linker script, -l and = have the same meaning as in the command line.
In addition to that, if a path is not absolute, the path needs to be searched
from the search paths. This patch implements them.

llvm-svn: 249967

llvm-svn: 249966

Previously, each ArgParser owned a BumpPtrAllocator, and arguments parsed
by an ArgParser would refer strings allocated using the BumpPtrAllocator
only when response files were used. This could cause a subtle bug because
such ownership was not obvious.

This patch moves the ownership from ArgParser to Driver and make the
ownership explicit.

llvm-svn: 249963

llvm-svn: 249962

SymbolTable was not a template class. Instead we had switch-case-based
type dispatch to call desired functions. We had to do that because
SymbolTable was created before we know what ELF type objects had been
passed.

Every time I tried to add a new function to the symbol table, I had to
define a dispatcher which consist of a single switch statement.

It also brought an restriction what the driver can do. For example,
we cannot add undefined symbols before any files are added to the symbol
table. That's because no symbols can be added until the symbol table
knows the ELF type, but when it knows about that, it's too late.

In this patch, the driver makes a decision on what ELF type objects
are being handled. Then the driver creates a SymbolTable object for
an appropriate ELF type.

http://reviews.llvm.org/D13544

llvm-svn: 249902

Parse and apply emulation given with -m option.
Check input files to match ELF type and machine architecture provided with -m.

Differential Revision: http://reviews.llvm.org/D13055

llvm-svn: 249529

Opening a file and dispatching to readLinkerScript() or createFile()
is a common operation. We want to use that at least from Driver and
from LinkerScript. In COFF, we had the same problem. This patch
resolves the problem in the same way as we did for COFF.

Now, if you have a path that you want to open, just call
Driver->addFile(StringRef). That function opens the file and handles
that as if that were given by command line. This function is the
only place we call identify_magic().

llvm-svn: 249023

This linker script parser and evaluator is powerful enough to read
Linux's libc.so, which is (despite its name) a linker script that
contains OUTPUT_FORMAT, GROUP and AS_NEEDED directives.

The parser implemented in this patch is a recursive-descendent one.
It does *not* construct an AST but consumes directives in place and
sets the results to Symtab object, like what Driver is doing.
This should be very fast since less objects are allocated, and
this is also more readable.

http://reviews.llvm.org/D13232

llvm-svn: 248918