This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld
used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error:
...". This matches what link.exe does (it prints "LINK : ...") and makes lld's
output less dependent on the host system.
https://reviews.llvm.org/D51133
llvm-svn: 340487
lld currently prepends the absolute path to itself to every diagnostic it
emits. This path can be longer than the diagnostic, and makes the actual error
message hard to read.
There isn't a good reason for printing this path: if you want to know which lld
you're running, pass -v to clang – chances are that if you're unsure of this,
you're not only unsure when it errors out. Some people want an indication that
the diagnostic is from the linker though, so instead print just the basename of
the linker's path.
Before:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
After:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
https://reviews.llvm.org/D49189
llvm-svn: 337634
Summary:
Any invocation of `clang -fuse-ld=lld` that results in a link command
on a macOS host currently fails, because the Darwin lld driver does not
recognize the `-lto_library` option that Clang passes it. Fix the error
by having the Darwin driver ignore the option.
The Clang driver's macOS toolchain is written such that it will always
pass the `-lto_library` option to the linker invocation on a macOS host.
And although the DarwinLdDriver is written to ignore any unknown arguments,
because `-lto_library` begins with `-l`, the DarwinLdDriver interprets it
as a library search command, for a library named "to_library". When the
DarwinLdDriver is unable to find a library specified via `-l`, it exits
with a hard error. This causes any invocation of `clang -fuse-ld=lld`
that results in a link command on a macOS host to fail with an error.
To fix the issue, I considered two alternatives:
1. Modify the Clang Darwin toolchain to only pass `-lto_library` if lld
is *not* being used. lld doesn't support LTO on Darwin anyway, so it
can't use the option. However, I opted against this because, if and
when lld *does* support LTO on Darwin, I'll have to make another
commit to Clang in order to get it to pass the option to lld again.
2. Modify the Darwin lld driver to ignore the `-lto_library` option.
Just in case users may take this to mean LTO is supported, I also
added a warning. If and when lld supports LTO on Darwin, the same
commit that adds support for this option can remove the warning.
Option (2) seemed better to me, and is the rationale behind this commit.
Test Plan: check-lld
Reviewers: ruiu, smeenai, pcc
Reviewed By: smeenai
Subscribers: JDevlieghere, pcc, mehdi_amini, inglorion, steven_wu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47994
llvm-svn: 334641
Summary:
Error handling in liblldCore and the Darwin toolchain prints to an
output stream. A TODO in the project explained that a diagnostics
interface resembling Clang's should be added.
For now, the simple diagnostics interface defined in liblldCommon seems
like an improvement. It prints colors when they're available, uses locks
for thread-safety, and abstracts away the `"error: "` and newline
literal strings that litter the Darwin toolchain code.
To use the liblldCommon error handler, a link dependency is added to
the liblldDriver library.
Test Plan:
1. check-lld
2. Invoke `ld64.lld -r` in a terminal that supports color output.
Confirm that "ld64.lld: error: -arch not specified and could not be inferred"
is output, and that the "error:" is colored red!
Reviewers: ruiu, smeenai
Reviewed By: ruiu
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D47998
llvm-svn: 334466
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Differential Revision: https://reviews.llvm.org/D44977
llvm-svn: 332351
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
This is patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
In this patch, Options.td was mainly changed in order to add value class
in Options.inc.
llvm-svn: 305805
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
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
These methods weren't really throwing errors. The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file. All of the callers
also ignored errors and just used the returned path if one was available.
Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.
llvm-svn: 264979
Pretty mechanical change here. Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>
llvm-svn: 264917
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
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
CoreDriver implements a driver for a hypothetical platform.
It is intended to be used in unittests. However, it is actually
redundant because the features are tested using the real driver
for the real platforms. So we can remove this.
http://reviews.llvm.org/D17698
llvm-svn: 262421
UniversalDriver was used as a dispatcher to each platform-specific driver.
It had its own Options.td file. It was not just too much to parse only a
few options (we only want to parse -core, -flavor or argv[0]),
but also interpreted arguments too early. For example, if you invoke lld as
"lld -flavor gnu ... -help", then you'd get the UniversalDriver's help
message instead of GnuDriver's. This patch eliminates the use of Options
from the dispatcher.
http://reviews.llvm.org/D17686
llvm-svn: 262190
Also added the defaults for whether to generate this load command, which
the cmdline options are able to override.
There was also a difference to ld64 which is fixed here in that ld64 will
generate an empty data in code command if requested.
rdar://problem/24472630
llvm-svn: 260191
This load command generates data in the LINKEDIT section which
is a list of ULEB128 delta's to all of the functions in the __text section.
It is then 0 terminated and pointer aligned to pad.
ld64 exposes the -function-starts and no-function-starts cmdline options
to override behaviour from the defaults based on file types.
rdar://problem/24472630
llvm-svn: 260188
This is of the form A.B.C.D.E and to match ld64's behaviour, is
always output to files, even when the version is 0.
rdar://problem/24472630
llvm-svn: 259746
Defaulting to unknown matches ld64, but it also makes sure that all
of our code can handle not knowing the platform. For example, a later
commit will add support for version min load commands with an unknown
platform, which is a feature supported by ld64.
No test case here. The next commit will have one with the version min
code that needed this patch.
llvm-svn: 259739
This option is emitted in the min_version load commands.
Note, there's currently a difference in behaviour compared to ld64 in
that we emit a warning if we generate a min_version load command and
didn't give an sdk_version. We need to decide what the correct behaviour
is here as its possible we want to emit an error and force clients to
provide the option.
llvm-svn: 259729
If the command line contains something like -macosx_version_min and we
don't explicitly disable generation with -no_version_load_command then
we generate the LC_VERSION_MIN command in the output file.
There's a couple of FIXME's in here. These will be handled soon with
more tests but I didn't want to grow this patch any more than it already was.
rdar://problem/24472630
llvm-svn: 259718
This adds the no_objc_category_merging cmdline option which will
be used in an upcoming commit to disable the category optimizer.
It is on by default in ld64 so we match that here.
Test case will come soon with the patch to make use of this option.
llvm-svn: 259439
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
This option matches the behaviour of ld64, that is it prevents globals
from being dead stripped in executables and dylibs.
Reviewed by Lang Hames
Differential Revision: http://reviews.llvm.org/D16026
llvm-svn: 258554
Summary: This is no longer needed now that the new ELF implementation supports AMDGPU.
Reviewers: ruiu, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15954
llvm-svn: 257390
Rui Ueyama