| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
b11386f9be9b2dc7276a758d64f66833da10bdea broke lld build
if `-DBUILD_SHARED_LIBS=ON` is passed to CMake.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is for those who use lld as a library. Context:
https://reviews.llvm.org/D70287
This patch adds a new parmeter to lld::*::link() so that we can pass
an raw_ostream object representing stdout. Previously, lld::*::link()
took only an stderr object.
Justification for making stdoutOS and stderrOS mandatory: I wanted to
make link() functions to take stdout and stderr in that order.
However, if we change the function signature from
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stderrOS = llvm::errs());
to
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stdoutOS = llvm::outs(),
raw_ostream &stderrOS = llvm::errs());
, then the meaning of existing code that passes stderrOS silently
changes (stderrOS would be interpreted as stdoutOS). So, I chose to
make existing code not to compile, so that developers can fix their
code.
Differential Revision: https://reviews.llvm.org/D70292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 304874
|
|
|
|
| |
llvm-svn: 304873
|
|
|
|
|
|
| |
The code in lib/ could use a lot of love :(
llvm-svn: 278506
|
|
|
|
| |
llvm-svn: 278505
|
|
|
|
| |
llvm-svn: 278327
|
|
|
|
| |
llvm-svn: 278181
|
|
|
|
| |
llvm-svn: 262195
|
|
|
|
| |
llvm-svn: 262184
|
|
|
|
| |
llvm-svn: 262181
|
|
|
|
|
|
|
|
| |
I believe this patch eliminates all remaining uses of _context
or _linkingContext variable names. Consistent naming improves
readability.
llvm-svn: 234645
|
|
|
|
| |
llvm-svn: 231444
|
|
|
|
|
|
| |
This hook is called from one of the hottest loops in LLD and does nothing.
llvm-svn: 231345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merge::mergeByLargestSection is half-baked since it's defined
in terms of section size, there's no way to get the section size
of an atom.
Currently we work around the issue by traversing the layout edges
to both directions and calculate the sum of all atoms reachable.
I wrote that code but I knew it's hacky. It's even not guaranteed
to work. If you add layout edges before the core linking, it
miscalculates a size.
Also it's of course slow. It's basically a linked list traversal.
In this patch I added DefinedAtom::sectionSize so that we can use
that for mergeByLargestSection. I'm not very happy to add a new
field to DefinedAtom base class, but I think it's legitimate since
mergeByLargestSection is defined for section size, and the section
size is currently just missing.
http://reviews.llvm.org/D7966
llvm-svn: 231290
|
|
|
|
| |
llvm-svn: 221974
|
|
|
|
| |
llvm-svn: 220131
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 219727
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mergeByContent attribute on DefinedAtoms triggers the symbol table to
coalesce atoms with the exact same content. The problem is that atoms can also
have a required custom section. The coalescing should never change the custom
section of an atom.
The fix is to only consider to atoms to have the same content if their
sectionChoice() and customSectionName() attributes match.
llvm-svn: 218893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined in a shared library.
Now LLD does not export a strong defined symbol if it coalesces away a
weak symbol defined in a shared library. This bug affects all ELF
architectures and leads to segfault:
% cat foo.c
extern int __attribute__((weak)) flag;
int foo() { return flag; }
% cat main.c
int flag = 1;
int foo();
int main() { return foo() == 1 ? 0 : -1; }
% clang -c -fPIC foo.c main.c
% lld -flavor gnu -target x86_64 -shared -o libfoo.so ... foo.o
% lld -flavor gnu -target x86_64 -o a.out ... main.o libfoo.so
% ./a.out
Segmentation fault
The problem is caused by the fact that we lose all information about
coalesced symbols after the `Resolver::resolve()` method is finished.
The patch solves the problem by overriding the
`LinkingContext::notifySymbolTableCoalesce()` method and saving names
of coalesced symbols. Later in the `buildDynamicSymbolTable()` routine
we use this information to export these symbols.
llvm-svn: 217363
|
|
|
|
| |
llvm-svn: 216257
|
|
|
|
|
|
|
|
|
|
| |
This is the one interesting aspect from:
http://reviews.llvm.org/D4965
These hooks are useful for flavor specific processing, such as recording that
a DefinedAtom replaced a weak SharedLibraryAtom.
llvm-svn: 216122
|
|
|
|
|
|
|
| |
isCoalescedAway(x) is faster than replacement(x) != x as the former
does not follow the replacement atom chain. Also it's easier to use.
llvm-svn: 210242
|
|
|
|
| |
llvm-svn: 209704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r205566, I made a change to Resolver so that Resolver revisit
only archive files in --start-group and --end-group pair. That's
not correct, as it also has to revisit DSO files.
This patch is to fix the issue.
Added a test to demonstrate the fix. I confirmed that it succeeded
before r205566, failed after r205566, and is ok with this patch.
Differential Revision: http://reviews.llvm.org/D3734
llvm-svn: 208797
|
|
|
|
| |
llvm-svn: 205643
|
|
|
|
| |
llvm-svn: 205642
|
|
|
|
| |
llvm-svn: 205641
|
|
|
|
| |
llvm-svn: 205639
|
|
|
|
|
|
| |
This reverts commit r205635 that was submitted by mistake.
llvm-svn: 205637
|
|
|
|
| |
llvm-svn: 205635
|
|
|
|
|
|
|
|
| |
This is cleaner and as efficient as before.
Differential Revision: http://llvm-reviews.chandlerc.com/D3284
llvm-svn: 205590
|
|
|
|
| |
llvm-svn: 205579
|
|
|
|
| |
llvm-svn: 205578
|
|
|
|
| |
llvm-svn: 205576
|
|
|
|
|
|
|
|
|
| |
If --allow-multiple-definition option is given, LLD does not treat duplicate
symbol error as a fatal error. GNU LD supports this option.
Differential Revision: http://llvm-reviews.chandlerc.com/D3211
llvm-svn: 205015
|
|
|
|
|
|
| |
Review : http://llvm-reviews.chandlerc.com/D3182
llvm-svn: 204830
|
|
|
|
|
|
|
|
|
|
| |
COMDAT_SELECT_LARGEST is a COMDAT type that make linker to choose the largest
definition from among all of the definition of a symbol. If the size is the
same, the choice is arbitrary.
Differential Revision: http://llvm-reviews.chandlerc.com/D3011
llvm-svn: 204172
|
|
|
|
|
|
|
|
|
|
| |
MergeCases table should not have an entry for MergeContents because atoms with
MergeContents attribute should never have name. This issue was not caught by a
test because getting a value of 6th element of an array of array actually gets
the first element's value of the next array, and that happened to be a valid
value. Added asserts to catch that error.
llvm-svn: 203322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
COMDAT_SELECT_SAME_SIZE is a COMDAT type that I presume exist only in COFF.
The semantics of the type is that linker should merge such COMDAT sections if
their sizes are the same. Otherwise it's an error.
Reviewers: Bigcheese, shankarke, kledzik
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2996
llvm-svn: 203308
|
|
|
|
| |
llvm-svn: 195663
|
|
|
|
| |
llvm-svn: 195662
|
|
|
|
| |
llvm-svn: 195661
|
|
|
|
| |
llvm-svn: 195051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can add multiple undefined atoms having the same name to the symbol table.
If such atoms are added, the symbol table compares their canBeNull attributes,
and select one having a stronger constraint. If their canBeNulls are the same,
the choice is arbitrary. Currently it choose the existing one.
This patch changes the preference, so that the symbol table choose the new one
if the new atom has a greater canBeNull or a fallback atom. This shouldn't
change the behavior except the case described below.
A new undefined atom may have a new fallback atom attribute. By choosing the new
atom, we can update the fallback atom during Core Linking. PE/COFF actually need
that. For example, _lseek is an alias for __lseek on Windows. One of an object
file in OLDNAMES.LIB has an undefined atom for _lseek with the fallback to
__lseek. When the linker tries to resolve _read, it supposed to read the file
from OLDNAMES.LIB and use the new fallback from the file. Currently LLD cannot
handle such case because duplicate undefined atoms with the same attributes are
ignored.
Differential Revision: http://llvm-reviews.chandlerc.com/D2161
llvm-svn: 194777
|
|
|
|
| |
llvm-svn: 194671
|
|
|
|
| |
llvm-svn: 194624
|
|
|
|
| |
llvm-svn: 194620
|