| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
I think it is clear by now that the new linker is viable.
llvm-svn: 262158
|
|
|
|
|
|
|
|
|
|
| |
HexagonEncodings.h contains a list of bitmasks. The file is used
only by HexagonRelocationHandler.cpp. The header is odd in the sense
that it uses struct Instruction but it doesn't define the data type.
This patch moves the struct definition to the header.
llvm-svn: 234947
|
|
|
|
| |
llvm-svn: 234938
|
|
|
|
| |
llvm-svn: 234868
|
|
|
|
|
|
|
| |
The data and the inline function defined in the header is used only
by HexagonRelocationHandler.cpp.
llvm-svn: 234867
|
|
|
|
|
|
|
| |
This file is not -Wconversion-clean, and seems like we don't care
about that except these lines. Fix these lines for simplicity.
llvm-svn: 234637
|
|
|
|
| |
llvm-svn: 234558
|
|
|
|
| |
llvm-svn: 234557
|
|
|
|
| |
llvm-svn: 234556
|
|
|
|
|
|
|
| |
In other ELF ports, we don't use the macro. This patch removes the
macro for consistency and readability.
llvm-svn: 234552
|
|
|
|
|
|
|
|
| |
Because no one except Hexagon uses the header, we don't need to maintain
the header in the common directory. Also de-template the function for
readability.
llvm-svn: 234551
|
|
|
|
|
|
|
|
| |
Functions in the files are hard to read because of line wrapping.
Use shorter names for local variables so that the lines fit
within 80 columns.
llvm-svn: 234087
|
|
|
|
|
|
|
| |
<Arch>TargetHandler.h and <ArcH>RelocationHandler.h include each other.
This patch breaks the circular dependencies.
llvm-svn: 234050
|
|
|
|
|
|
|
| |
At least in Mips we don't have a prefix for member variables.
Repeating the architecture is verbose.
llvm-svn: 233746
|
|
|
|
|
|
|
| |
FINDV4BITMASK macro is defined as a macro so that the macro body is inlined.
We should use inlined functions instead of macros.
llvm-svn: 233719
|
|
|
|
| |
llvm-svn: 231005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nothing wrong with reinterpret_cast<llvm::support::ulittle32_t *>(loc),
but that's redundant and not great from readability point of view.
The new functions are wrappers for that kind of reinterpet_casts.
Surprisingly or unsurprisingly, there was no use of big endian read
and write. {read,write}{16,32,64}be have no user. But I think they
still worth to be there in the header for completeness.
http://reviews.llvm.org/D7927
llvm-svn: 230725
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment errors in relocation processing such as out of range
values are not detected or at best trapped by asserts which will not
be present in release builds. This patch adds support for checking
error return values from applyRelocation() calls and printing an
appropriate error message. It also adds support for printing multiple
errors rather than just the first one.
llvm-svn: 226557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At present each TargetRelocationHandler generates a pretty similar error
string and calls llvm_unreachable() when encountering an unknown
relocation. This is not ideal for two reasons:
1. llvm_unreachable disappears in release builds but we still want to
know if we encountered a relocation we couldn't handle in release
builds.
2. Duplication is bad - there is no need to have a per-architecture error
message.
This change adds a test for AArch64 to test whether or not the error
message actually works. The other architectures have not been tested
but they compile and check-lld passes.
llvm-svn: 223782
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209948
|
|
|
|
|
|
|
|
| |
X86_64,X86,PPC,Hexagon,Mips
No change in functionality.
llvm-svn: 200177
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Use of static is recommended by the style guide.
llvm-svn: 196877
|
|
|
|
|
|
| |
It was never transporting any value in addition to the error_code.
llvm-svn: 194028
|
|
|
|
|
|
|
|
|
| |
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: 181852
|
|
|
|
| |
llvm-svn: 178495
|
|
|
|
| |
llvm-svn: 178027
|
|
|
|
| |
llvm-svn: 177970
|
|
|
|
| |
llvm-svn: 177484
|
|
|
|
| |
llvm-svn: 176415
|
|
|
|
| |
llvm-svn: 176298
|
|
|
|
| |
llvm-svn: 176277
|
|
|
|
| |
llvm-svn: 176162
|
|
|
|
| |
llvm-svn: 174658
|
|
hexagonrelocationhander
llvm-svn: 174148
|