The `OutputSection::appendSection()` method always gets a pointer
to the `Section` class descendants. So it is not necessary to keep them
in the vector of `Chunk` pointers.
No functional changes.
llvm-svn: 235392
There's (almost) never need to keep .L symbols around for production
builds. In fact, the FreeBSD kernel explicitly specify -X beacuse the
size impact (and the subsequent performance impact) might be significant,
because we keep symbols in memory.
I was tempted to make this the default, but I haven't (yet).
PR: 23232
llvm-svn: 235357
Before we only accepted --dynamic-linker=<file> and -dynamic-linker <file>
but older versions of GNU ld (e.g. 2.17.50) accept this other form, so
try to be compatible.
PR: 23233
llvm-svn: 235282
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
This function is too long and complicated. Looks like new code was
added incrementaly without any refactoring. Maybe no one can describe
its exact semantics any more? It even contains copy-pastes inside it.
This patch is an (incomplete) attempt to simplify the function.
I tried to mechanically translate code to another form more intelligible.
I don't still understand the whole picture, but this patch shouldn't
change the linker's functionality.
llvm-svn: 234944
That helps to correctly write content of hash table if target and host
endianness are not the same. Right now that commit does not affect
any supported targets.
llvm-svn: 234928
We don't need to repeat the template argument. They are not
ambiguous. MIPS is parameterized for ELFT, so we can't do this
for MIPS, though.
llvm-svn: 234913
This patch tries to fix the following MSVC warning.
warning C4661: 'bool
lld:🧝:ELFFile<lld:🧝:ELF32LE>::isCompatible(unsigned
char,unsigned char)' : no suitable definition provided for explicit
template instantiation request
llvm-svn: 234909
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
The function took either StringRef or Twine. Since string literals are
ambiguous when resolving the overloading, many code calls used this
function with explicit type conversion. That led awkward code like
make_dynamic_error_code(Twine("Error occurred")).
This patch adds a function definition for string literals, so that
you can directly call the function with literals.
llvm-svn: 234841
DynamicFile and ELFFile are instantiated for four different types,
ELF{32,64}{BE,LE}. Because the classes are instantiated in each
compilation unit, including the header file makes object files
10MB larger.
On Windows, issue of excessive template instantiation is critical,
since the regular COFF file supports only up to 65534 sections.
(We could use the extended COFF file format, but generating that
much COMDAT sections is not a good thing in the first place
because it means long compile time and long link time.)
I confirmed that this change makes AArch64TargetHandler.cpp.o
from 21MB to 8.5MB. It feels still too large, but I think it's
a good start.
llvm-svn: 234808
This is a follow-up to r234728 and r234729. It looks like explicit
instantiation of `MipsELFFile` is redundant and triggers Visual C++ warning.
llvm-svn: 234756
This patch adds support for overflow checking when processing
R_AARCH64_CALL26, R_AARCH64_JUMP26, R_AARCH64_CONDBR19,
R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21, and R_AARCH64_TLSLE_ADD_TPREL_HI12
relocations.
llvm-svn: 234749
This patch makes the AArch64GotAtomContent, AArch64Plt0AtomContent, and
AArch64PltAtomContent static and also cleanup their formatting.
llvm-svn: 234745
I can't access my Windows machine at the moment, but the build was breaking with:
c:\b\build\slave\crwinclanglld\build\src\third_party\llvm\tools\lld\lib\readerwriter\elf\mips\MipsTargetLayout.h(38) : error C2440: 'return' : cannot convert from 'lld:🧝:MipsGOTSection<ELFT> *' to 'lld:🧝:AtomSection<ELFT> *'
with
[
ELFT=lld:🧝:Mips32ELType
]
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
I think this regressed caused in 234727: that the forward-declarations
of MipsGOTSection<> is not enough.
llvm-svn: 234736
Right now MIPS instantiates MipsTargetHandler using Mips32ELType and
Mips64ELType. And in the future we can add a couple more types. That
leads to the large object file size because compiler has to create
copies of MipsTargetHandler and all realted classes for each types used
for instantiation.
The patch introduces two factory functions and puts each of them into
the separate cpp file. That allows to reduce size of single object file.
llvm-svn: 234728
This doesn't compile with MSVC 2013:
include\lld/ReaderWriter/PECOFFLinkingContext.h(356) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
include\lld/ReaderWriter/PECOFFLinkingContext.h(357) : error C2797:
'lld::PECOFFLinkingContext::_imageVersion': list initialization
inside member initializer list or non-static data member initializer
is not implemented
llvm-svn: 234676
I believe this patch eliminates all remaining uses of _context
or _linkingContext variable names. Consistent naming improves
readability.
llvm-svn: 234645
The Native file format was designed to be the fastest on-memory or
on-disk file format for object files. The problem is that no one
is working on that. No LLVM tools can produce object files in
the Native, thus the feature of supporting the format is useless
in the linker.
This patch removes the Native file support. We can add it back
if we really want it in future.
llvm-svn: 234641
This MIPS specific option controls R_MIPS_EH relocation handling.
If -pcrel-eh-reloc is specified R_MIPS_EH relocation should be handled
like R_MIPS_PC32 relocation.
llvm-svn: 234635
The patch supports just the R_MIPS_EH relocation handling and does not
implement full specification of compact exception tables for MIPS ABIs.
llvm-svn: 234634
When we call getGP() we need in fact _gp symbol address. Let's cache its
value and return it directly from the new getGPAddr() function.
llvm-svn: 234632
Because calls of applyRelocation is parallelized, all functions
called from that need to be thread-safe. This piece of code
didn't use any synchronization mechanism, so it was not safe.
llvm-svn: 234628
This includes implementation of PLT0 entry.
For testing, libfn.so binary is added since
there's no way to link shared objects with lld yet.
llvm-svn: 234588
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
CreateELF.h was included only by ELFReader.h, and it was used only
by ELFReader class. By making the function a member of the class,
we can remove template parameters.
llvm-svn: 234540
atom_collection is basically a wrapper for std::vector. The class
provides begin and end member functions, so that it "hides" the
other member functions provided by std::vector. However, you can
still directly access _atoms member since the member is not
protected.
We cannot simply make the member private because we need that member
when we are constructing atom vectors.
This patch splits atom_collection into two types: std::vector<Atom *>
and AtomRange. When we are constructing atom vectors, we use the
former class. We return instances of the latter class from File
objects so that callers cannot add or remove atoms from the lists.
std::vector<Atom *> is automatically converted to AtomRange.
llvm-svn: 234450
It's a follow-up to r234347. We do not need to keep a reference to
`GOTFile` instance in a xxxWriter class after ownership is transferred
to the caller of the `createImplicitFiles` method.
llvm-svn: 234396
It's not our business to resolve those undefined symbols.
We just trust the linker will load the library and its dependencies
correctly, which is actually what happens, modulo bugs in the dynamic
linker itself.
PR: 23035
Differential Revision: http://reviews.llvm.org/D8886
llvm-svn: 234378
SimpleFile defines defined(). undefined(), sharedLibrary() and absolute().
We should use the class instead of deriving from the base class and
re-defining the member functions in ELFFile.
llvm-svn: 234367
Now 'writer' creates an instance of `RuntimeFile` in the constructor, then
populates the file in the virtual function `addDefaultAtoms`, then pass
owning of this file to the caller of virtual function `createImplicitFiles`.
First, we do not need to keep an instance of `RuntimeFile` so long. It is
enough to create the file, right after that populate it and pass the owning.
Second, relationship between `createImplicitFiles` and `addDefaultAtoms`
is complicated. The `createImplicitFiles` might call `addDefaultAtoms`,
overridden version of `addDefaultAtoms` might call base class `addDefaultAtoms`,
and overridden version of `createImplicitFiles` might call base class
`createImplicitFiles` as well as `addDefaultAtoms`.
The patch solves both problems above. It creates and populates runtime files
right in the createImplicitFiles(), removes `addDefaultAtoms` at all and
does not keep references to runtime files in class fields.
llvm-svn: 234347
Make PLT entry atoms represent mapping symbols in the Release mode,
while in the Debug mode they are still function-like symbols
with regular names.
It's legal that mapping symbols denote unnamed parts of code,
and PLT entries are not required to have function-like names.
Differential Revision: http://reviews.llvm.org/D8819
llvm-svn: 234301
Maybe we can interpret alignment 0 as "don't care", but for
consistency, it's good to set 1 instead of 0 where we allow
any alignments.
llvm-svn: 234284
createAtom function did too much in a single for-loop. This patch
splits the for-loop and extract COMDAT handling into a separate
function.
llvm-svn: 234276
handleDefinedSymbol has return type of ErrorOr<ELFDefinedAtom *>.
However, it never returns an error. We are not checking errors.
It's marked as ErrorOr "just in case". That's a bad engineering
practice.
This patch simplifies the return type of the function.
llvm-svn: 234269
Previously, we put both link-once and group sections into the same map
and seaparated them out when we use them. Apparently we should put them
into seaprate maps in the first place.
This piece of code is added recently, and I still don't understand all
of them. Looks like we need to clean this up even more.
llvm-svn: 234223
The error was introduced during mechanical replacement
of raw memory reads/writes to use readxxle/writexxle functions
in r230725.
Noted and fixed by Suprateeka R Hegde <hegdesmailbox@gmail.com>
llvm-svn: 234144
This matches other linkers behaviour. Moreover, there's really
no need to keep them around.
Reported by: Rafael Avila de Espindola
PR: 22890
llvm-svn: 234130
In case of MIPS N64 ABI linker should merge registers usage masks stored
in the input .MIPS.options sections and save result into the output
.MIPS.options section.
llvm-svn: 234115
In case of MIPS O32 ABI linker should merge registers usage masks stored
in the input .reginfo sections and save result into the output .reginfo
section.
The ABI states that the .reginfo section should be put into the separate
segment. This requirement is not implemented in this patch.
llvm-svn: 234103
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
These functions are "constructors" of the LinkingContexts. We already
have auxiliary classes and functions for ELFLinkingContext in the header.
They fall in the same category.
llvm-svn: 234082
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
canParse took three parameters -- file magic, filename extension and
memory buffer. All but YAMLReader ignored the second parameter.
This patch removes the parameter.
llvm-svn: 234080
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
So that we can remove one template parameter from ELFReader.
ELF port is heavily templatized, and I want to reduce the usage
where possible.
llvm-svn: 234074
Only MIPS defined the member function, but this feature is not actually
MIPS-specific. Also, the dependency to the MIPS-only member function
prevented us from merging <Arch>ELF{Object,DSO}Reader classes.
This patch moves the feature from MipsLinkingContext to LinkingContext.
llvm-svn: 234068
<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
All <Arch>ELFFileCreateFileTraits structs are the same except its file type.
That means that we don't need to pass the type traits. Instead, we can only
pass file types. By doing this, we can remove copy-pasted boilerplates.
llvm-svn: 234047
What we are doing in ELFTarget.h was dubious. In the file, we define
partial classes of <Arch>LinkingContexts to declare only static member
functions. We have different (complete) class definitions in other files.
They would conflict if they exist in the same compilation unit (because
the ones defined in ELFTarget.h has only static member functions).
I don't think this was valid C++.
http://reviews.llvm.org/D8797
llvm-svn: 234039
This patch provides implementation of R_ARM_TARGET1 relocation with
configuration of its behaviour from a command line. This patch provides
two command line options for GnuLd driver: --arm-target1-rel and
--arm-target1-abs (similar to ld option names with extra prefix 'arm-').
So user may choose which behaviour of R_ARM_TARGET1 is preferred for his
implementation of libc.
Differential Revision: http://reviews.llvm.org/D8707
llvm-svn: 234009
result_type is always ErrorOr<unique_ptr<File>>, and since the type traits
is for instantiating ELF files, it's unlikely that we want to return
something else. This patch removes that type.
llvm-svn: 233948
Since we no longer support MSVC 2012, we can assume that variadic
templates are always supported. This patch removes an #ifdef for
C++ compilers that don't support variadic templates.
llvm-svn: 233901
The function call that goes through PLT table may be performed
from both ARM and Thumb code.
This situation requires adding a veneer to original PLT code
(which is always ARM) to effect Thumb-to-ARM transition.
Differential Revision: http://reviews.llvm.org/D8701
llvm-svn: 233900
There is one-to-one correspondence between ELF machine type and a
LinkingContext. We passed them as separate arguments to the constructor.
This patch is to teach the LinkingContexts about their machine types,
so that we don't need to pass that data as separate arguments.
llvm-svn: 233894
Looks like MipsTargetHandler::_runtimeFile is unused.
MipsRuntimeFile doesn't seem to add values to the base class,
so I removed that class too.
llvm-svn: 233888
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
Also removed some over-generalization added in r232866, such as
making a function take two parameters and pass two equivalent
arguments to the function.
llvm-svn: 233882
Other createWriter<Arch> functions take <Arch>LinkingContext as arguments.
Only createWriterELF was an exception. This patch makes it consistent with
others.
llvm-svn: 233878
<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
All calls of findAbsoluteAtoms seem a bit awkward because of the type
of the function. It semantically returns a pointer to an AtomLayout or
nothing, so I made the function return AtomLayout*.
In this patch, I also expanded some "auto"s because their actual type
were not obvious in their contexts.
llvm-svn: 233769
Multiple inheritance is casually used here. Rewriting to not
using multiple inheritance reduces the complexity of the code
and also makes it shorter.
llvm-svn: 233718
Type of `OutputSection::_type` field is int64_t. This change makes
the field's and the argument's types consistent and allows to assign
full range of values to the `OutputSection::_type` field.
llvm-svn: 233617
If input relocation records have RELA format while output dynamic
relocations have REL format the only way to transfer a dynamic
relocation addendum is to save it into the location modified by
the dynamic relocation.
llvm-svn: 233532
Setting _alignment member varaible to 0 look suspicious since
the minimum alignment value is 1. I'm not going to change that
number in this patch, though.
llvm-svn: 233472
If HAVE_CXXABI_H is not defined, this function is the identity function.
Because HAVE_CXXABI_H did not protect the entire function, it did
extra stuffs before returning the argument.
The new code calls fewer functions. This should help developers understand
this piece of code.
llvm-svn: 233460
This diff includes implementation of linking calls to ifunc functions.
It provides ifunc entries in PLT and corresponding relocations (R_ARM_ALU_PC_G0_NC,
R_ARM_ALU_PC_G1_NC, R_ARM_LDR_PC_G2 for link-time and R_ARM_IRELATIVE for run-time).
Differential Revision: http://reviews.llvm.org/D7833
llvm-svn: 233277
Mapping symbols should have their own code models,
and in some places must be treated in a specific way.
Make $t denote Thumb code, and $a and $d denote ARM code.
Set size, binding and type of mapping symbols to what the specification says.
Differential Revision: http://reviews.llvm.org/D8601
llvm-svn: 233259
This patch defines implicit conversion between integers and PowerOf2
instances, so uses of the classes is now implicit and look like
regular integers. Now we are ready to remove the scaffolding.
llvm-svn: 233245
The new constructor's type is the same, but this one takes not a log2
value but an alignment value itself, so the meaning is totally differnet.
llvm-svn: 233244
This patch is to make instantiation and conversion to an integer explicit,
so that we can mechanically replace all occurrences of the class with
integer in the next step.
Now get() returns an alignment value rather than its log2 value.
llvm-svn: 233242
We are using log2 values and values themselves to represent alignments.
For example, alignment 8 is sometimes represented as 3 (8 == 2^3).
We want to stop using log2 values.
Because both types are regular arithmetic types, we cannot get help from
a compiler to find places we mix two representations. That makes this
merging work surprisingly hard because if I make a mistake, I'll just get
wrong results at runtime (Yay types!). In this patch, I introduced
a class to represents power-of-two values, which is basically an alias
for an integer type.
Once the migration is done, the class will be removed.
llvm-svn: 233232
Import Lookup Table in Import Directory Table has the same contents
as Hint/Name Table. Symbol names imported from DLLs are pointed by
both Import Directory Table and Hint/Name Table. We had duplicate
strings there.
This patch eliminates that duplication to make the table smaller.
This should reduce binary size by the sum of lengths of imported
symbols.
llvm-svn: 233128
Visual C++ shows the "right shift by too large amount" warning if
`MipsELFReference` is instantiated for 32-bit target and `Elf_Rel_Impl::getType`
method has `unsigned char` return type. We can freely suppress the warning in
that case because MIPS 32-bit ABI does not pack multiple relocation types into
the single field `r_type` and the `MipsELFReference::_tag` should be always
zero in that case.
No functional changes.
llvm-svn: 233088
Denis Protivensky