| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 267221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are properties of a symbol name, rather than a particular instance
of a symbol in an object file. We can simplify the code by collecting these
properties in Symbol.
The MustBeInDynSym flag has been renamed ExportDynamic, as its semantics
have been changed to be the same as those of --dynamic-list and
--export-dynamic-symbol, which do not cause hidden symbols to be exported.
Differential Revision: http://reviews.llvm.org/D19400
llvm-svn: 267183
|
|
|
|
| |
llvm-svn: 267045
|
|
|
|
|
|
|
| |
It is a pity that we have to create a TargetMachine once per thread,
so at least make that code as small as possible.
llvm-svn: 266578
|
|
|
|
|
|
| |
Emit an error instead.
llvm-svn: 266504
|
|
|
|
|
|
|
|
| |
Parallelism level can be chosen using the new --lto-jobs=K option
where K is the number of threads used for CodeGen. It currently
defaults to 1.
llvm-svn: 266484
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18994
llvm-svn: 266009
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18872
llvm-svn: 265956
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now MustBeInDynSym is only true if the symbol really must be in the
dynamic symbol table.
IsUsedInRegularObj is only true if the symbol is used in a .o or -u. Not
a .so or a .bc.
A benefit is that this is now done almost entirilly during symbol
resolution. The only exception is copy relocations because of aliases.
This includes a small fix in that protected symbols in .so don't force
executable symbols to be exported.
This also opens the way for implementing internalize for -shared.
llvm-svn: 265826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, there are some cases when the IR Linker produces a broken
module (which doesn't pass the verifier) and we end up asserting
inside the verifier. I think it's always a bug producing a module
which does not pass the verifier but there are some cases in which
people can live with the broken module (e.g. if only DebugInfo
metadata are broken). The gold plugin has something similar.
This commit is motivated by a situation I found in the
wild. It seems that somebody else discovered it independently
and reported in PR24923.
llvm-svn: 265258
|
|
|
|
|
|
| |
Thanks to Rui for the suggestion; this simplifies things.
llvm-svn: 265213
|
|
|
|
|
|
| |
The argv[0] is based on the analogous thing in clang.
llvm-svn: 265206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes bootstrap of llvm-tblgen (with LTO) and PR27150.
Slightly longer explanation follows.
Emission of .init_array instead of .ctors is supported only on a
subset of the Target LLVM supports. Codegen needs to be conservative
and always emit .ctors unless instructed otherwise (based on target).
If the dynamic linker sees .init_array it completely ignores
what's inside .ctors and therefore some constructors are not called
(and this causes llvm-tblgen to crash on startup).
Teach LLD/LTO about the Codegen options so we end up always emitting
.init_array and avoid this issue.
In future, we might end up supporting mix of .ctors and .init_array
in different input files if this shows up as a real-world use case.
The way gold handles this case is mapping .ctors from input into
.init_array in output. There's also another caveat because
as far as I understand .ctors run in reverse order so when we do
the copy/mapping we need to reverse copy in the output if there's
more than one ctor. That's why I'd rather avoid this complicate logic
unless there's a real need.
An analogous reasoning holds for .dtors/.fini_array.
llvm-svn: 265085
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18667
llvm-svn: 265053
|
|
|
|
|
|
| |
Requested by: Rui Ueyama.
llvm-svn: 264809
|
|
|
|
| |
llvm-svn: 264791
|
|
|
|
|
|
|
| |
If a symbol appears in @llvm.used, the linker is forced to treat
the symbol as there's a reference to it.
llvm-svn: 264790
|
|
|
|
|
|
|
| |
Because it doesn't have to be fixed even though it is probably
better to do.
llvm-svn: 264772
|
|
|
|
| |
llvm-svn: 264770
|
|
|
|
|
|
| |
We treat that in the same way we treat shared libraries.
llvm-svn: 264698
|
|
|
|
|
|
|
|
|
|
|
| |
IPO doesn't work very well across symbols referenced
by others TUs. The linker here tries to evaluate
which symbols are safe to internalize and switches
their linkage.
Differential Revision: http://reviews.llvm.org/D18415
llvm-svn: 264585
|
|
|
|
|
|
| |
Suggested by: Rui Ueyama.
llvm-svn: 264518
|
|
|
|
|
|
| |
http://reviews.llvm.org/D18410
llvm-svn: 264193
|
|
|
|
|
|
|
| |
Similarly to how we do with linkonce_odr symbols already, but
change their linkage to weak.
llvm-svn: 264181
|
|
|
|
| |
llvm-svn: 264171
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure we keep the symbol we need to before it reaches
the Writer (and hit an assertion), changing its linkage
from linkonce_odr to weak. For a more detailed description
of the problem, see PR19901 where a similar problem was
fixed for the gold plugin. Thanks to Rafael for providing
a testcase.
llvm-svn: 264111
|
|
The code for LTO has been growing, so now is probably a good time to
move it to its own file. SymbolTable.cpp is for symbol table, and
because compiling bitcode files are semantically not a part of
symbol table, this is I think a good thing to do.
http://reviews.llvm.org/D18370
llvm-svn: 264091
|