| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 198987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main goal of this patch is to allow "mach-o encoded as yaml" and "native
encoded as yaml" documents to be intermixed. They are distinguished via
yaml tags at the start of the document. This will enable all mach-o test cases
to be written using yaml instead of checking in object files.
The Registry was extend to allow yaml tag handlers to be registered. The
mach-o Reader adds a yaml tag handler for the tag "!mach-o".
Additionally, this patch fixes some buffer ownership issues. When parsing
mach-o binaries, the mach-o atoms can have pointers back into the memory
mapped .o file. But with yaml encoded mach-o, name and content are ephemeral,
so a copyRefs parameter was added to cause the mach-o atoms to make their
own copy.
llvm-svn: 198986
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is to basically move the functionality to construct Data Directory
from IdataPass to WriterPECOFF.
Data Directory is a part of the PE/COFF header and contains the addresses of
the import tables.
We used to represent the link from Data Directory to the import tables as
relocation references. The idea behind it is that, because relocation
references are processed by the Writer, we wouldn't have to do anything special
to fill the addresses of the import tables. I thought that the addresses would
be set "automatically".
But it turned out that that design made the pass and the writer rather
complicated. In order to make relocation references between Data Directory to
the import tables, these data structures needed to be represented as Atom.
However, because Data Directory is not a section content but a part of the
PE/COFF header, it did not fit well as an Atom. So we ended up having
complicated code both in IdataPass and the writer.
This patch simplifies it.
One side effect of this patch is that we now have ".idata.a", ".idata.d" and
"idata.t" sections for the import address table, the import directory table,
and the import lookup table. The writer looks for the sections by name to find
the start addresses of the sections. We probably should have a better way to
find a specific atom from the core linking result, but currently using the
section name seems to be the easiest way to do that. The Windows loader do not
care about the import table's section layout.
llvm-svn: 197016
|
|
|
|
| |
llvm-svn: 194278
|
|
|
|
| |
llvm-svn: 194037
|
|
|
|
| |
llvm-svn: 193482
|
|
|
|
| |
llvm-svn: 193477
|
|
|
|
| |
llvm-svn: 192277
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This also makes it support debugging executables built with lld.
Initial patch done by Bigcheese. This is only a revised patch to
have the functionality in the Writer.
llvm-svn: 191032
|
|
|
|
| |
llvm-svn: 190903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 190554
|
|
|
|
|
|
| |
reference. Move readFile logic into FileNode::createLinkerInput.
llvm-svn: 190253
|
|
|
|
|
|
|
|
|
|
| |
It looks like there is a possibility of seeing RO/RW note sections
and we would need to create an appropriate RO/RW segment associated
with them.
Adds a test too.
llvm-svn: 189907
|
|
|
|
|
|
|
|
| |
Emit note sections if the input contains a note section.
Also emit a note segment.
llvm-svn: 189896
|
|
|
|
|
|
|
|
|
|
|
| |
typeTLV content type is used by Darwin to represent thread local
storage. A new contentType has to be made to represent ELF
thread local storage data. These have been set to
- typeThreadZeroFill (represents TBSS storage)
- typeThreadData (represents TDATA storage)
llvm-svn: 189137
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 188049
|
|
|
|
|
|
|
|
|
| |
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 178913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 175901
|
|
|
|
| |
llvm-svn: 174916
|
|
|
|
| |
llvm-svn: 173570
|
|
|
|
| |
llvm-svn: 173430
|
|
|
|
| |
llvm-svn: 173300
|
|
|
|
|
|
| |
It owns and manages passes.
llvm-svn: 173287
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
constants and string literals which the linker should coalesce.
llvm-svn: 172495
|
|
|
|
| |
llvm-svn: 172338
|
|
|
|
|
|
| |
This removes a bunch of llvm_unreachables and makes a File's mutability part of the type system.
llvm-svn: 172297
|
|
|
|
|
|
|
|
|
|
| |
Since most content types (e.g. typeCode) have a
preferred Permission, add a function to do that mapping.
Then hook up to YAML Reader and Writer such that
the 'permissions:' key does not need to be specified unless
overriding what the content type prefers.
llvm-svn: 171929
|
|
|
|
| |
llvm-svn: 171918
|
|
|
|
| |
llvm-svn: 171898
|
|
|
|
| |
llvm-svn: 171645
|
|
|
|
|
|
|
|
| |
and adds a new file ReaderWriterYAML.cpp that uses YAML I/O.
Lots of tweaks to test suite for slightly different YAML encoding.
llvm-svn: 171592
|