llvm-svn: 293966

Summary: llvm/CodeGen/CommandFlags.h a utility function InitTargetOptionsFromCodeGenFlags which is used to set target options from flags based on the command line. The command line flags are stored in globals defined in the same file, and including the file in multiple places causes the globals to be defined multiple times, leading to linker errors. This change adds a single place in lld where these globals are defined and exports only the utility function. This makes it possible to call InitTargetOptionsFromCodeGenFlags from multiple places in lld, which a follow-up change will do.

Reviewers: davide, ruiu

Reviewed By: davide, ruiu

Subscribers: mgorny

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

llvm-svn: 293965

Summary:
Lld's build had a couple of issues which prevented a successfull
LLVM_LINK_LLVM_DYLIB compilation.

- add_llvm_library vs llvm_add_library: One adds a library to libLLVM.so, other
  one doesn't. Lld was using the wrong one, causing symbols to be mupltiply
  defined in things linking to libLLVM.
- confusion when to use LINK_LIBS vs LINK_COMPONENTS in llvm_add_library
- not using LLVM_LINK_COMPONENTS for add_lld_tool

With these fixes lld compiles and it's test suite passes both in
LLVM_LINK_LLVM_DYLIB mode and without it.

Reviewers: ruiu, beanz

Subscribers: llvm-commits, mgorny

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

llvm-svn: 291432

This patch moves convertToUnixPathSeparator from LLD to LLVM.

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

llvm-svn: 291414

Should bring back the windows bots.

llvm-svn: 291263

llvm-svn: 291223

Now TarWriter takes care of path separator conversion, so we don't
need to handle that in LLD.

llvm-svn: 291221

This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.

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

llvm-svn: 291210

llvm-svn: 288975

llvm-svn: 288972

Currently LLD prints basename of source file name in error messages,
for example:
$ mkdir foo
$ echo 'void _start(void) { foobar(); }' > foo/bar.c
$ gcc -g -c foo/bar.c
$ bin/ld.lld -o out bar.o 
bin/ld.lld: error: bar.c:1: undefined symbol 'foobar'
$
This should say:
bin/ld.lld: error: foo/bar.c:1: undefined symbol 'foobar'

This is PR31299

Differential revision: https://reviews.llvm.org/D27506

llvm-svn: 288966

Apparently this is wrong because it's legal to have a filename
on UNIX which contains a backslash.

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

llvm-svn: 287143

llvm-svn: 286712

Patch replaces forward slashes with backward inside response.txt

This is https://llvm.org/bugs/show_bug.cgi?id=30951.

Differential revision: https://reviews.llvm.org/D26443

llvm-svn: 286589

This would trigger an assertion at runtime otherwise.

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

llvm-svn: 286562

Previously, we do this piece of code to iterate over all input sections.

  for (elf::ObjectFile<ELFT> *F : Symtab.getObjectFiles())
    for (InputSectionBase<ELFT> *S : F->getSections())

It turned out that this mechanisms doesn't work well with synthetic
input sections because synthetic input sections don't belong to any
input file.

This patch defines a vector that contains all input sections including
synthetic ones.

llvm-svn: 286051

Differential revision: https://reviews.llvm.org/D26320

llvm-svn: 286030

Differential revision: https://reviews.llvm.org/D26293

llvm-svn: 286000

llvm-svn: 284671

The code in lib/ could use a lot of love :(

llvm-svn: 278506

llvm-svn: 278505

llvm-svn: 278327

llvm-svn: 278181

llvm-svn: 277926

llvm-svn: 277760

llvm-svn: 276720

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

make_dynamic_error_code was used to create a std::error_code with
a std::string message.  Now that we are migrating to llvm::Error,
there are no calls to these make_dynamic_error_code methods.

There is one single call to make_dynamic_error_code remaining, the one
inside GenericError::convertToErrorCode().  That method is only called
from File::doParse() which should be a temporary situation.  We need
to work out how to deal with File::parse() caching the error result from
doParse().  Caching errors isn't supported in the new scheme, and probably
isn't needed here, but we need to work that out.

Once thats done, dynamic error and all utilities around it can be deleted.

llvm-svn: 264982

This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.

llvm-svn: 264961

llvm-svn: 264951

This updates most of the file handling methods in the linking context and
resolver to use the new API.

llvm-svn: 264924

Adds a GenericError class to lld/Core which can carry a string.  This is
analygous to the dynamic_error we currently use in lld/Core.

Use this GenericError instead of make_dynamic_error_code.  Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have.  This will go away once
all the APIs are converted.

llvm-svn: 264910

searchArchivesToOverrideTentativeDefinitions and
searchSharedLibrariesToOverrideTentativeDefinitions are always false.
For the dead flags, we have a fairly large amount of code which is
never be executed.

http://reviews.llvm.org/D17791

llvm-svn: 264653

This is a re-commit of r264022 with a fix for MSVC.  The issue there was
that the code was running DefinedAtom::~Atom() for some value and instead
needed to cast to Atom before running ~Atom.  Original commit message follows.

Currently each File contains an BumpPtrAllocator in which Atom's are
allocated.  Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.

Now each File actually owns its Atom's using an OwningAtomPtr.  This
is analygous to std::unique_ptr and may be replaced by it if possible.

An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another.  The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's.  This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.

Should hopefully fix the remaining leaks.  Will keep an eye on the bots to
make sure.

llvm-svn: 264067

This reverts commit r264022.

This breaks the Window's bots which don't like that i'm calling ~Atom when
the this pointer is a sublcass of Atom.

Reverting for now until I try find a better fix.  I tried using std::unique_ptr with
a custom deleter as a quick fix, but it didn't work well in the YAML parser.

llvm-svn: 264023

Currently each File contains an BumpPtrAllocator in which Atom's are
allocated.  Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.

Now each File actually owns its Atom's using an OwningAtomPtr.  This
is analygous to std::unique_ptr and may be replaced by it if possible.

An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another.  The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's.  This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.

Should hopefully fix the remaining leaks.  Will keep an eye on the bots to
make sure.

llvm-svn: 264022

llvm-svn: 262447

llvm-svn: 262445

llvm-svn: 262444

llvm-svn: 262443