| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 202054
|
|
|
|
| |
llvm-svn: 197834
|
|
|
|
| |
llvm-svn: 197788
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes are in:
include/lld/Core/Reference.h
include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.
1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers. It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.
The new model is that there is a global Registry object. You programmatically
register the Readers you want with the registry object. Whenever you need to
read/parse a file, you ask the registry to do it, and the registry tries each
registered reader.
For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object.
2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings. Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values. The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value. This tuple system allows conversion to and from strings with
no ambiguities.
llvm-svn: 197727
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 196053
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeReferenceIvarsV1 cannot handle more than 65535 relocation targets
because its field to point to the target table is of type uint16_t. Because
of that limitation, the LLD couldn't link a file containing more than 65535
relocations. 65535 is not a big number - the LLD couldn't even link itself
with V1.
This patch solves the issue by adding NativeReferenceIvarsV2 support. The
new structure has more bits for the target table, so it can handle a large
number of relocatinos.
V2 structure is larger than V1. In order to prevent file bloating, V2 format
is used only when the resulting file cannot be represented in V1 format. The
writer and the reader support both V1 and V2 formats.
Differential Revision: http://llvm-reviews.chandlerc.com/D2217
llvm-svn: 195270
|
|
|
|
| |
llvm-svn: 195096
|
|
|
|
| |
llvm-svn: 194988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The maximum number of references the file with NativeReferenceIvarsV1 can
contain is 65534. If a file larger than that is converted to Native format,
the conversion will fail without any error message. This caused a subtle bug
that the LLD would produce a broken executable only when input files contain
too many references.
This issue exists since the RoundTripNativeTest is introduced in r193585. Since
then, it seems that nobody have linked any program having more than 65534
relocations with the LLD. Otherwise we would have found it earlier.
llvm-svn: 194987
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 194914
|
|
|
|
| |
llvm-svn: 194913
|
|
|
|
| |
llvm-svn: 194911
|
|
|
|
| |
llvm-svn: 194909
|
|
|
|
| |
llvm-svn: 194908
|
|
|
|
|
|
| |
end() was evaluated every time through a loop. This patch eliminates it.
llvm-svn: 194894
|
|
|
|
| |
llvm-svn: 194890
|
|
|
|
| |
llvm-svn: 194887
|
|
|
|
| |
llvm-svn: 194877
|
|
|
|
| |
llvm-svn: 194866
|
|
|
|
| |
llvm-svn: 194776
|
|
|
|
| |
llvm-svn: 194278
|
|
|
|
| |
llvm-svn: 194037
|
|
|
|
|
|
| |
Patch reviewed by Shankar Easwaran.
llvm-svn: 194010
|
|
|
|
|
|
|
|
| |
There is no test as currently there is no call to the NativeWriter.
Future commits will add calls to the NativeWriter.
llvm-svn: 192944
|
|
|
|
| |
llvm-svn: 192261
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes :-
a) Functionality in InputGraph to insert Input elements at any position
b) Functionality in the Resolver to use nextFile
c) Move the functionality of assigning file ordinals to InputGraph
d) Changes all inputs to MemoryBuffers
e) Remove LinkerInput, InputFiles, ReaderArchive
llvm-svn: 192081
|
|
|
|
| |
llvm-svn: 191466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In COFF, an undefined symbol can have up to one alternative name. If a symbol
is resolved by its regular name, then it's linked normally. If a symbol is not
found in any input files, all references to the regular name are resolved using
the alternative name. If the alternative name is not found, it's a link error.
This mechanism is called "weak externals".
To support this mechanism, I added a new member function fallback() to undefined
atom. If an undefined atom has the second name, fallback() returns a new undefined
atom that should be used instead of the original one to resolve undefines. If it
does not have the second name, the function returns nullptr.
Differential Revision: http://llvm-reviews.chandlerc.com/D1550
llvm-svn: 190625
|
|
|
|
|
|
| |
reference. Move readFile logic into FileNode::createLinkerInput.
llvm-svn: 190253
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BSS atoms dont take any file space in the Input file. They are associated
with a contentType(typeZeroFill). Similiar zero fill types also exist which
have the same meaning in terms of occupying file space in the Input.
These atoms have to be handled seperately when writing to the
lld's intermediate file or the lld test infrastructure.
Also adds a test.
llvm-svn: 189136
|
|
|
|
|
|
|
|
|
| |
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
|
|
|
|
| |
llvm-svn: 186450
|
|
|
|
| |
llvm-svn: 184589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Architecture specific code should reside in architecture specific directory
not in Atom. Looks like there are no efforts being made at this moment to
support ARM, so let's remove it for now.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D959
llvm-svn: 183877
|
|
|
|
|
|
| |
in the string table for static linking
llvm-svn: 180692
|
|
|
|
| |
llvm-svn: 178918
|
|
|
|
| |
llvm-svn: 178914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The major changes are:
1) LinkerOptions has been merged into TargetInfo
2) LinkerInvocation has been merged into Driver
3) Drivers no longer convert arguments into an intermediate (core) argument
list, but instead create a TargetInfo object and call setter methods on
it. This is only how in-process linking would work. That is, you can
programmatically set up a TargetInfo object which controls the linking.
4) Lots of tweaks to test suite to work with driver changes
5) Add the DarwinDriver
6) I heavily doxygen commented TargetInfo.h
Things to do after this patch is committed:
a) Consider renaming TargetInfo, given its new roll.
b) Consider pulling the list of input files out of TargetInfo. This will
enable in-process clients to create one TargetInfo the re-use it with
different input file lists.
c) Work out a way for Drivers to format the warnings and error done in
core linking.
llvm-svn: 178776
|
|
|
|
|
|
| |
Improves performance.
llvm-svn: 177556
|
|
|
|
|
|
| |
This is the standard way of implementing LLVM RTTI.
llvm-svn: 177555
|
|
|
|
| |
llvm-svn: 177079
|
|
|
|
| |
llvm-svn: 175983
|
|
|
|
| |
llvm-svn: 173570
|
|
|
|
| |
llvm-svn: 173430
|
|
|
|
| |
llvm-svn: 173300
|
|
|
|
|
|
|
|
| |
I really would have liked to split this patch up, but it would greatly
complicate the lld-core and lld drivers having to deal with both
{Reader,Writer}Option and TargetInfo.
llvm-svn: 173217
|
|
|
|
|
|
| |
This removes a bunch of llvm_unreachables and makes a File's mutability part of the type system.
llvm-svn: 172297
|
|
|
|
| |
llvm-svn: 169306
|
|
|
|
|
|
|
|
|
|
|
| |
* Moves enum Scope from DefinedAtom.h to Atom.h
* Adds scope method to AbsoluteAtom class
* Updates YAML to print scope of AbsoluteAtoms
* Update Native Reader/Writer to handle this new, "attribute"
* Adds testcase
Reviewed and approved by Nick Kledzik
llvm-svn: 166189
|
|
|
|
| |
llvm-svn: 163573
|