| 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: 246334
|
|
|
|
| |
llvm-svn: 242014
|
|
|
|
|
|
|
| |
The .reginfo should not belong to the separate segment if there is
a .MIPS.abiflags section.
llvm-svn: 238688
|
|
|
|
|
|
|
|
| |
New MipsAbiInfoHandler merges and hold both ELF header flags
and registries usage masks. In the future commits it will manage some
additional information.
llvm-svn: 238684
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 238310
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
|
|
|
| |
llvm-svn: 232360
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is initial patch to support MIPS64 object files linking.
The patch just makes some classes more generalized, and rejects
attempts to interlinking O32 and N64 ABI object files.
I try to reuse the current MIPS target related classes as much as
possible because O32 and N64 MIPS ABI are tightly related and share
almost the same set of relocations, GOT, flags etc.
llvm-svn: 227058
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 227048
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
These classes contain only abstract virtual functions. Explicit
constructors are redundant.
llvm-svn: 226265
|
|
|
|
|
|
|
| |
That reduce class dependencies and simplify the code a bit.
No functional changes.
llvm-svn: 226255
|
|
|
|
|
|
|
| |
The change is rather large but mainly it just adds handling of new relocations,
PLT entries etc.
llvm-svn: 224826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Tested with check-lld with no regressions.
llvm-svn: 223462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. The path checks ELF header flags to prevent linking of incompatible files.
For example we do not allow to link files with different ABI, -mnan
flags, some combination of target CPU etc.
2. The patch merge ELF header flags from input object files to put their
combination to the generated file. For example, if some input files
have EF_MIPS_NOREORDER flag we need to put this flag to the output
file header.
I use the `parseFile()` (not `canParse()`) method because in case of
recognition of incorrect input flags combination we should show detailed
error message and stop the linking process and should not try to use
another `Reader`.
llvm-svn: 221439
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 213310
|
|
|
|
|
|
| |
R_MIPS_TLS_LDM etc.
llvm-svn: 210394
|
|
|
|
| |
llvm-svn: 209582
|
|
|
|
| |
llvm-svn: 207949
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Re-implement PLT entries and dynamic relocations emitting to keep PLT
and relocations table in a consistent state.
2. Initialize st_value and st_other fields for dynamic symbols table
entry if this entry corresponds to an external function which address is
taken in a non-PIC executable. In that case the st_value field holds an
address of the function's PLT entry. Also set STO_MIPS_PLT bit in the
st_other field.
llvm-svn: 207494
|
|
|
|
| |
llvm-svn: 206018
|
|
|
|
|
|
|
|
|
| |
of GOT.
* Read addend for R_MIPS_GOT16 relocation.
* Put only high 16 bits of symbol + addend into GOT entries for
locally visible symbols.
llvm-svn: 204247
|
|
|
|
|
|
| |
a uniform way.
llvm-svn: 204246
|
|
|
|
|
|
| |
and MipsDynamicSymbolTable classes fields.
llvm-svn: 203400
|
|
|
|
|
|
| |
by the returned pointer dereferencing.
llvm-svn: 203399
|
|
|
|
| |
llvm-svn: 203398
|
|
|
|
| |
llvm-svn: 201129
|
|
|
|
|
|
|
|
| |
X86_64,X86,PPC,Hexagon,Mips
No change in functionality.
llvm-svn: 200177
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 200166
|
|
|
|
|
|
|
| |
Later we need to improve that solution and build a correct set of flags
by merging ELF flags from all input objects.
llvm-svn: 199555
|
|
|
|
| |
llvm-svn: 199516
|
|
|
|
|
|
| |
sections will be implemented later.
llvm-svn: 199515
|
|
|
|
| |
llvm-svn: 199241
|
|
|
|
| |
llvm-svn: 199240
|
|
|
|
| |
llvm-svn: 199239
|
|
|
|
|
|
|
| |
_GLOBAL_OFFSET_TABLE_ symbol. We do not use this ponter anywhere after
assigning of virtual address.
llvm-svn: 199237
|
|
|
|
|
|
| |
MipsTargetLayout class method.
llvm-svn: 199236
|
|
|
|
|
|
| |
the lowest segment address to the MIPS_BASE_ADDRESS dynamic tag.
llvm-svn: 199234
|
|
|
|
|
|
| |
paired LO16 relocation.
llvm-svn: 198790
|
|
|
|
|
|
| |
internal purpose. Use special LLD_R_MIPS_GLOBAL_GOT constant for that.
llvm-svn: 198787
|
|
|
|
| |
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
|
|
The following are the most significant peculiarities of MIPS target:
- MIPS ABI requires some special tags in the dynamic table.
- GOT consists of two parts local and global. The local part contains
entries refer locally visible symbols. The global part contains entries
refer global symbols.
- Entries in the .dynsym section which have corresponded entries in the
GOT should be:
* Emitted at the end of .dynsym section
* Sorted accordingly to theirs GOT counterparts
- There are "paired" relocations. One or more R_MIPS_HI16 and R_MIPS_GOT16
relocations should be followed by R_MIPS_LO16 relocation. To calculate
result of R_MIPS_HI16 and R_MIPS_GOT16 relocations we need to combine
addends from these relocations and paired R_MIPS_LO16 relocation.
The patch reviewed by Michael Spencer, Shankar Easwaran, Rui Ueyama.
http://llvm-reviews.chandlerc.com/D2156
llvm-svn: 197342
|