| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
I think it is clear by now that the new linker is viable.
llvm-svn: 262158
|
|
|
|
| |
llvm-svn: 234862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, ELFReader takes three template arguments: EFLT,
LinkingContextT and FileT. FileT is itself templated.
So it was a bit complicated. Maybe too much.
Most architectures don't actually need to be parameterized for ELFT.
For example, x86 is always ELF32LE and x86-64 is ELF64LE.
However, because ELFReader requires a ELFT argument, we needed
to parameterize a class even if not needed.
This patch removes the parameter from the class. So now we can
de-templatize such classes (I didn't do that in this patch, though).
This patch also removes ContextT parameter since it didn't have to be
passed as a template argument.
llvm-svn: 234853
|
|
|
|
| |
llvm-svn: 234823
|
|
|
|
| |
llvm-svn: 234790
|
|
|
|
|
|
|
|
|
|
| |
getRelocationHandler is a public interface to get an instance of
TargetRelocationHandler. We don't use any member function other than
applyRelocations to a returned instance. Returning a base class instance
suffices here. (If a return type is a derived class, it looks like we were
using derived classes features.)
llvm-svn: 234081
|
|
|
|
|
|
|
|
|
|
| |
Because of the previous change (r234074), ELFObjectReader became just
an alias for ELFReader. We can replace all occurrences of ELFObjectReader
with ELFReader.
In this patch, I also replaced ELFDSOReader to remove the alias template.
llvm-svn: 234076
|
|
|
|
|
|
|
|
|
|
|
| |
<Arch>ELFReader.h contains only a few typedefs. The typedefs are used
only by one class in <Arch>TargetHandler.h. Thus, the headers don't
worth to be independent files.
Since MipsELFReader.h contains code other than the boilerplate, I didn't
touch that file in this patch.
llvm-svn: 234056
|
|
|
|
| |
llvm-svn: 233897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<Arch>ELFLinkingContext.
registerRelocationNames() function is called to register all known
ELF relocation types to the central registry. Since we have separate
LinkingContext class for each ELF machine type, we need to call the
function for each LinkingContext.
However, the function belonged to TargetHandler instead of LinkingContext.
So we needed to do ctx.getTargetHandler().registerRelocationNames().
This patch removes that redundant getTargetHandler call by moving the
function from TargetHandler to LinkingContext.
Conceptually this patch is small, but in reality it's not that small.
It's because the same code is copied to each architecture.
Most of this patch is just repetition. We need to merge them, but
that cannot be done in this patch.
llvm-svn: 233883
|
|
|
|
| |
llvm-svn: 233880
|
|
|
|
|
|
| |
members.
llvm-svn: 233873
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<Arch>TargetHandler::kindString is a static member variable
containg a list of names of relocation types.
The member is used only by one function, registerRelocationNames,
so they don't have to be a static member.
This patch makes the visibility of the data narrower by making
them file-scoped variables in small files.
llvm-svn: 233867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r233772, I removed an empty class, DefaultTargetHandler, from
the class hierarchy by merging the class with TargetHandler. I then
found that TargetHandler and its base class, TargetHandlerBase,
are also almost the same.
We need to go deeper.
In this patch, I merged TargetHandlerBase with TargetHandler.
The only difference between them is the existence (or absense)
of a pure virtual function registerRelocationName(). I added that
function to the (new) TargetHandler.
One more thing is that TargetHandler was templated for no reason.
I made it non-templated class.
llvm-svn: 233773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DefaultTargetHandler is the base class of all <Arch>TargetHandler classes,
and it's the only derived class of TargetHandler class.
TargetHandler and DefaultTargetHandler are actually the same. They define
the same set of pure virtual functions. DefaultTargetHandler is a useless
class in the class hierarchy -- it shouldn't have been added in the first place.
This patch makes all <Arch>TargetHandler classes directly derive from
TargetHandler and removes DefaultTargetHandler.
llvm-svn: 233772
|
|
|
|
|
|
|
| |
Only MIPS used that member function, and by removing the use of the
function, I removed a static_cast. Seems like it's a win.
llvm-svn: 233748
|
|
|
|
|
|
|
| |
Apparently they are copy-pastes. They need to be merged, or otherwise
they will diverge needlessly as I did in r233723...
llvm-svn: 233741
|
|
|
|
| |
llvm-svn: 233344
|
|
|
|
| |
llvm-svn: 233319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the LinkingContext parameter to the ELFReader. Previously the flags in
that were needed in the Context was passed to the ELFReader, this made it very
hard to access data structures in the LinkingContext when reading an ELF file.
This change makes the ELFReader more flexible so that required parameters can be
grabbed directly from the LinkingContext.
Future patches make use of the changes.
There is no change in functionality though.
llvm-svn: 228905
|
|
|
|
|
|
|
|
|
|
| |
The canParse function for all the ELF subtargets check if the input files match
the subtarget.
There were few mismatches in the input files that didnt match the subtarget for
which the link was being invoked, which also acts as a test for this change.
llvm-svn: 220182
|
|
|
|
|
|
|
|
|
| |
This would permit the ELF reader to check the architecture that is being
selected by the linking process.
This patch also sorts the include files according to LLVM conventions.
llvm-svn: 220129
|
|
|
|
| |
llvm-svn: 210831
|
|
|
|
| |
llvm-svn: 205056
|
|
|
|
|
|
| |
requiring MSVC 2012 or newer.
llvm-svn: 202626
|
|
|
|
|
|
|
|
| |
X86_64,X86,PPC,Hexagon,Mips
No change in functionality.
llvm-svn: 200177
|
|
|
|
| |
llvm-svn: 197788
|
|
|
|
| |
llvm-svn: 197737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
It was never transporting any value in addition to the error_code.
llvm-svn: 194028
|
|
|
|
| |
llvm-svn: 192310
|
|
|
|
|
|
|
|
|
| |
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-ELF writers.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D977
llvm-svn: 184061
|
|
|
|
| |
llvm-svn: 173966
|
|
llvm-svn: 173909
|