N64 ABI relocation record r_info field in fact consists of five subfields:
* r_sym - symbol index
* r_ssym - special symbol
* r_type3 - third relocation type
* r_type2 - second relocation type
* r_type - first relocation type
Up to three these relocations applied one by one. The first relocation
uses an addendum from the relocation record. Each subsequent relocation
takes as its addend the result of the previous operation. Only the final
operation actually modifies the location relocated. The first relocation
uses as a reference symbol specified by the `r_sym` field. The third
relocation assumes NULL symbol.
The patch represents these data using LLD model and takes in account
additional relocation types during a relocation calculation.
Additional relocations do not introduce any new relations between two
atoms and just specify operations need to be done during a relocation
calculation. The first relocation type (`r_type`) stored in the
`Reference::_kindValue`. The rest of relocations and `r_ssym` value are
stored in the new `Reference::_tag` field "as-is". I decided to do not
"decode" these data on the core LLD level to prevent pollution of the
core LLD model by very target specific data.
Also I have to override writing of relocation records in the `RelocationTable`
class to convert MIPS N64 ABI relocation information from the `Reference`
class back to the ELF relocation record.
http://reviews.llvm.org/D8533
llvm-svn: 233057
Merge::mergeByLargestSection is half-baked since it's defined
in terms of section size, there's no way to get the section size
of an atom.
Currently we work around the issue by traversing the layout edges
to both directions and calculate the sum of all atoms reachable.
I wrote that code but I knew it's hacky. It's even not guaranteed
to work. If you add layout edges before the core linking, it
miscalculates a size.
Also it's of course slow. It's basically a linked list traversal.
In this patch I added DefinedAtom::sectionSize so that we can use
that for mergeByLargestSection. I'm not very happy to add a new
field to DefinedAtom base class, but I think it's legitimate since
mergeByLargestSection is defined for section size, and the section
size is currently just missing.
http://reviews.llvm.org/D7966
llvm-svn: 231290
MIPS ELF symbols might contain some additional MIPS-specific flags
in the st_other field besides visibility ones. These flags indicate
code properties like microMIPS / MIPS16 encoding, position independent
code etc. We need to transfer the flags from input objects to the
output linked file to write them into the symbol table, adjust symbols
addresses etc.
I add new attribute CodeModel to the DefinedAtom class to hold target
specific flag and to get over YAML/Native format conversion barrier.
Other architectures/targets can extend CodeModel enumeration by their
own flags.
MIPS specific part of this patch adds support for STO_MIPS_MICROMIPS
flag. This flag marks microMIPS symbols. Such symbol should:
a) Has STO_MIPS_MICROMIPS in the corresponding .symtab record.
b) Has adjusted (odd) address in the corresponding .symtab
and .dynsym records.
llvm-svn: 221864
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
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
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
* 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
now Reader and Writer subclasses for each file format. Each Reader and
Writer subclass defines an "options" class which controls how that Reader
or Writer operates.
llvm-svn: 157774
Simon Atanasyan