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
Summary: This is similar to D46290 D46320.
Reviewers: ruiu, grimar
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D46861
llvm-svn: 332372
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
Patch by Patricio Villalobos.
I discovered that lld for darwin is generating the wrong code for lazy
bindings in the __stub_helper section (at least for osx 10.12). This is
the way i can reproduce this problem, using this program:
#include <stdio.h>
int main(int argc, char **argv) {
printf("C: printf!\n");
puts("C: puts!\n");
return 0;
}
Then I link it using i have tested it in 3.9, 4.0 and 4.1 versions:
$ clang -c hello.c
$ lld -flavor darwin hello.o -o h1 -lc
When i execute the binary h1 the system gives me the following error:
C: printf!
dyld: lazy symbol binding failed:
BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB
has segment 4 which is too large (0..3)
dyld: BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is too
large (0..3)
Trace/BPT trap: 5
Investigating the code, it seems that the problem is that the asm code
generated in the file StubPass.cpp, specifically in the line 323,when it
adds, what it seems an arbitrary number (12) to the offset into the lazy
bind opcodes section, but it should be calculated depending on the
MachONormalizedFileBinaryWrite::lazyBindingInfo result.
I confirmed this bug by patching the code manually in the binary and
writing the right offset in the asm code (__stub_helper).
This patch fixes the content of the atom that contains the assembly code
when the offset is known.
Differential Revision: https://reviews.llvm.org/D35387
llvm-svn: 311734
This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding LLVM change is r306878.
llvm-svn: 306880
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
Without this, when building with shared BUILD_SHARED_LIBS=ON
I get errors such as:
lib/Core/Reader.cpp:40: error: undefined reference to
'llvm::identify_magic(llvm::StringRef)'
Differential Revision: https://reviews.llvm.org/D34004
llvm-svn: 304932
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
This is one step in preparation of raising this up to
LLVM. This hides all of the Executor stuff in a private
implementation file, leaving only the core algorithms and
the TaskGroup class exposed. In doing so, fix up all the
variable names to conform to LLVM style.
Differential Revision: https://reviews.llvm.org/D32890
llvm-svn: 302288
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
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 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
I thought for a while about how to remove it, but it looks like we
can just copy the file for now. Of course I'm not happy about that,
but it's just less than 50 lines of code, and we already have
duplicate code in Error.h and some other places. I want to solve
them all at once later.
Differential Revision: https://reviews.llvm.org/D27819
llvm-svn: 290062
Remove the includes of <llvm/Config/config.h> private LLVM header.
The relevant files seem not to use any definitions from that file,
and it is not available when building against installed LLVM.
The use in lib/ReaderWriter/MachO/MachOLinkingContext.cpp originates
from rL218718, and the use in ELF/Strings.cpp from rL274804 (where it
was moved from Symbols.cpp). In both cases, they were added as a part of
demangling support, and they provided HAVE_CXXABI_H.
Since we are now using the LLVM demangler library instead, the code was
removed and the includes and no longer necessary.
Differential Revision: https://reviews.llvm.org/D27757
llvm-svn: 289707
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
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
It only makes sense to set on N_NO_DEAD_STRIP on a relocatable object file. Otherwise the bits aren't useful for anything. Matches the ld64 behaviour.
llvm-svn: 278419
We should be using one of BIND_OPCODE_SET_DYLIB_SPECIAL_IMM, BIND_OPCODE_SET_DYLIB_ORDINAL_IMM,
and BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB depending on whether ordinals are <= 0, <= 15, > 15.
This matches the behaviour of ld64.
llvm-svn: 278407
We already had logic for binding opcodes had the same addend as last time. This adds
the cases where the ordinal, symbol name, type, and segment offsets are the same as
the last emitted ordinal.
This gets us one step closer to emitting rebase opcodes as compressed as ld64 can manage.
llvm-svn: 278405
Currently we do this when an atom is used, but we need to do it when a
dylib is referenced on the cmdline as this matches ld64.
This fixes much confusion over which maps are indexed with installName
vs path. There is likely other confusion so i'll be seeing if i can remove
path() completely in a future commit as path() shouldn't really be needed by anyone.
llvm-svn: 278396
A version of 0x1000 is 0.16.0, not 1.0.0 as the comment said. Fix the
value to match the comment, and also the one test case which had this
wrong.
llvm-svn: 278381
Using vmsize to populate this file works when outputing MachO images, but fails
when outputting relocatable objects. This patch fixes the computation to use
file offsets, which works for both output types.
Fixes <rdar://problem/27727666>
llvm-svn: 278297
The export trie was being emitted in the order the nodes were
added to the vector, but instead needs to be visited in the order
that the nodes are traversed. This matches the behaviour of ld64.
llvm-svn: 277869
Nico Weber