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
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
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
The aforementioned relocation generate a GOT entry with a
R_X86_64_TPOFF64. The new relocation is processed at startup
time by the loader. lld didn't generate the outstanding relocation,
now it does. This bug was found while trying to link ls(1) on FreeBSD.
Simplified repro:
#include <stdio.h>
#include <wchar.h>
#include <wctype.h>
int
main(void)
{
wchar_t wc = 98;
if (!iswprint(wc))
printf("blah\n");
else
printf("foo\n");
return (0);
}
which incorrectly outputs "blah" when linked with lld before this patch.
llvm-svn: 233051
separately
This change reduce difference between the trunk and upcoming patch and
simplify the future code review.
No functional changes.
llvm-svn: 232919
This changes improves performance of lld, when self-hosting lld, when compared
with the bfd linker. BFD linker on average takes 8 seconds in elapsed time.
lld takes 3 seconds elapased time average. Without this change, lld takes ~5
seconds average. The runtime comparisons were done on a release build and
measured by running linking thrice.
lld self-host without the change
----------------------------------
real 0m3.196s
user 0m4.580s
sys 0m0.832s
lld self-host with lld
-----------------------
user 0m3.024s
user 0m3.252s
sys 0m0.796s
time taken to build lld with bfd
--------------------------------
real 0m8.419s
user 0m7.748s
sys 0m0.632s
llvm-svn: 232460
I knew I cut corners when I wrote this. Turned out that it is
actually slow when a file being read has many symbols. This patch
is to stop doing linear search and instead do map lookup.
llvm-svn: 232436
The `eh_frame_ptr` field in the `.eh_frame_hdr` section contains an address
of the `.eh_frame` section. Using an absolute 32-bit format for encoding
of this field does not work for 64-bit targets. It is better to use a
relative format because it covers both 32-bit and 64-bit cases. Sure
this work if a distance between `.eh_frame_hdr` and `.eh_frame` sections
is less than 4 Gb but it is a rather correct assumption.
http://reviews.llvm.org/D8352
llvm-svn: 232414
Puts symbols defined in linker script expressions in a runtime file that is
added as input to the resolver, making the input object files see symbols
defined in linker scripts.
http://reviews.llvm.org/D8263
llvm-svn: 232409
This commit implements the behaviour of the SECTIONS linker script directive,
used to not only define a custom mapping between input and output sections, but
also order input sections in the output file. To do this, we modify
DefaultLayout with hooks at important places that allow us to re-order input
sections according to a custom order. We also add a hook in SegmentChunk to
allow us to calculate linker script expressions while assigning virtual
addresses to the input sections that live in a segment.
Not all SECTIONS constructs are currently supported, but only the ones that do
not use special sort orders. It adds two LIT test as practical examples of
which sections directives are currently supported.
In terms of high-level changes, it creates a new class "script::Sema" that owns
all linker script ASTs and the logic for linker script semantics as well.
ELFLinkingContext owns a single copy of Sema, which will be used throughout
the object file writing process (to layout sections as proposed by the linker
script).
Other high-level change is that the writer no longer uses a "const" copy of
the linking context. This happens because linker script expressions must be
calculated *while* calculating final virtual addresses, which is a very late
step in object file writing. While calculating these expressions, we need to
update the linker script symbol table (inside the semantics object), and, thus,
we are "modifying our context" as we prepare to write the file.
http://reviews.llvm.org/D8157
llvm-svn: 232402
The gotSymbol need not be a global static variable. Apart from this reason, This
variable was creating an issue with self hosting lld, as there seems to be an
issue running global initializers, when initializing the guard for this static
variable.
Program received signal SIGTRAP, Trace/breakpoint trap.
llvm-svn: 232341
Handle resolution of symbols coming from linked object files lazily.
Add implementation of handling _GLOBAL_OFFSET_TABLE_ and __exidx_start/_end symbols for ARM platform.
Differential Revision: http://reviews.llvm.org/D8159
llvm-svn: 232261
The Segment Chunk had two functions one to append a section and one to append a
chunk. A section is a subclass of a chunk and clearly this can be merged into
one single function.
llvm-svn: 232249
GNU LD has an option named -T/--script which allows a user to specify
a linker script to be used [1]. LLD already accepts linker scripts
without this option, but the option is widely used. Therefore it is
best to support it in LLD as well.
[1] https://sourceware.org/binutils/docs/ld/Options.html#Options
llvm-svn: 232183
the spec required by std::sort and friends.
Ordering things this way also dramatically simplifies the code as
short-circuit ensures we can skip all of the negative tests.
I've left one FIXME where we're establishing a fairly arbitrary
ordering. Previously, the function compared all types as equal except
for the ones it explicitly handled, but it didn't delegate correctly to
the atomflags when doing so, and so it would fail to be a SWO. The two
possible fixes are to stop comparing the atom flags entirely, or to
establish some arbitrary ordering of the types.
Since it was pure luck which ordering of unequal types we ended up with
previously (the caller was std::sort, not std::stable_sort) I chose to
make the ordering explicit and guaranteed. This seems like the best
conservative approach as I suspect we would want to switch to
stable_sort otherwise in order to have deterministic output.
Differential Revision: http://reviews.llvm.org/D8266
llvm-svn: 231968
This patch implements parsing of the GNU ld MEMORY command [1].
The command and the memory block definitions are parsed as
specified (including the slightly strange "o" and "l" keywords).
Evaluation will be added at a later point in time.
[1] https://sourceware.org/binutils/docs-2.25/ld/MEMORY.html
llvm-svn: 231928
This will be replaced by a more generic class to handle
all the default symbols in an executable, e.g. __init_array.
Differential Revision: http://reviews.llvm.org/D8234
Reviewed by: shankare
llvm-svn: 231906
of the vector. For a vector 'v', '&v[v.size()]' isn't a valid way to
compute a pointer one-past-the-end of the vector. Instead, write the
loop in terms of iterators and save the beginning iterator. Once we have
that we can compute the beginning pointer from the beginning iterator,
and compute the distance which we should increment the beginning pointer
by subtracting the iterators.
What might be simpler would be to convert the function accepting a raw
pointer for begin and end to accept iterators or a range or some other
construct, but I wanted to keep this to a minimal bug-fix change.
This fixes a crash on any debug STL implementation which checks for
indexing out of bounds.
llvm-svn: 231765
The expression evaluation is needed when interpreting linker scripts, in order
to calculate the value for new symbols or to determine a new position to load
sections in memory. This commit extends Expression nodes from the linker script
AST with evaluation functions, and also contains a unit test.
http://reviews.llvm.org/D8156
llvm-svn: 231707
1. Move relocation addendum reading code to the MipsRelocationHandler
class to reduce code duplication.
2. Factor out the relocations calculation code into the separate
function to be ready to handle MIPS N64 ABI relocation chains.
No functional changes.
llvm-svn: 231641
We should not take in account a type of "source" symbol. Cross mode jump
adjustment is requred when target symbol and relocation belong to
different (regular/microMIPS) instruction sets.
llvm-svn: 231639
All readers except PE/COFF reader create layout-after edges to preserve
the original symbol order. PE/COFF uses layout-before edges as primary
edges for no reason.
This patch makes PE/COFF reader to create layout-after edges.
Resolver is updated to recognize reverse edges of layout-after edges
in the garbage collection pass.
Now we can retire layout-before edges. I don't do that in this patch
because if I do, I would have updated many tests to replace all
occurrrences of "layout-before" with "layout-after". So that's a TODO.
llvm-svn: 231615
If an output is large, its base relocation section can be also large.
For example, chrome.dll is almost 300 MB, and it has about 9 million
base relocations. Creating the section took 1.5 seconds on my machine.
This patch changes the way to create the section so that we can use
parallel_sort to group base relocations by high bits. This change
makes the linker almost 4% faster for the above test case on my machine.
If I replace parallel_sort with std::sort, performance remains the same,
so single thread performance should remain the same.
This has no functionality change. The output should be identical as
before.
llvm-svn: 231585
This patch reverts r231545 "PECOFF: Do not add extraneous symbols
to the dead strip root." CrWinClangLLD buildbot is currently broken.
Since I can't reproduce the issue locally, I'm reverting the most
relevant change.
llvm-svn: 231582
Previously we added all undefined symbols found in object files to
the dead strip root. This patch makes the linker to stop doing that.
Undefined symbols would be resolved anyway, so this patch doesn't
change the linker behavior. It should slightly improve performance
but it's really marginal. This is a cleanup.
llvm-svn: 231545
Previously applying 1 million relocations took about 2 seconds on my
Xeon 2.4GHz 8 core workstation. After this patch, it takes about 300
milliseconds. As a result, time to link chrome.dll becomes 23 seconds
to 21 seconds.
llvm-svn: 231454
The last use of layout-after edge for PE/COFF was removed in r231290.
Now layout-after edges do nothing. We can stop adding them to the graph.
No functionality change intended.
llvm-svn: 231301
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
File objects are not really const in the resolver. We set ordinals to
them and call beforeLink hooks. Also, File's member functions marked
as const are not really const. ArchiveFile never returns the same
member file twice, so it remembers files returned before. find() has
side effects.
In order to deal with the inconsistencies, we sprinkled const_casts
and marked member varaibles as mutable.
This patch removes const from there to reflect the reality.
llvm-svn: 231212
std::promise and std::future in old version of libstdc++ are buggy.
I think that's the reason why LLD tests were flaky on Ubuntu 13
buildbots until we disabled file preloading.
In this patch, I implemented very simple future and used that in
FileArchive. Compared to std::promise and std::future, it lacks
many features, but should serve our purpose.
http://reviews.llvm.org/D8025
llvm-svn: 231153
Yet another chapter in the story. We're getting there, finally.
Note for the future: the tests for relocation have a lot of duplication
and probably can be unified in a single file. Let's reevaluate this once
the support will be complete (hopefully, soon).
llvm-svn: 231057
"virtual" was present at a wrong place. FileArchive is a subclass of
ArchiveLibraryFile, and a FileArchive can be deleted through a
pointer of ArchiveLibraryFile. We want to make the destructor of the
base class virtual.
llvm-svn: 231033
This reverts commit r230086. I added a lock to guard FileCOFF::doParse(),
which killed parallel file parsing. Now the buildbots got back to green,
I believe the threading issue was resolved, so it's time to remove the
guard to see if it works with the buildbots.
llvm-svn: 230886
In doParse, we shouldn't do anything that has side effects. That function may be
called speculatively and possibly in parallel.
We called WinLinkDriver::parse from doParse to parse a command line in a .drectve
section. The parse function updates a linking context object, so it has many side
effects. It was not safe to call that function from doParse. beforeLink is a
function for a File object to do something that has side effects. Moving a call
of WinLinkDriver::parse to there.
llvm-svn: 230791
If no initial live symbols are set up, and deadStrip() == true,
the Resolver ends up reclaiming all the symbols that aren't absolute. This is wrong.
This patch fixes the issue by setting entrySymbolName() as live, and this allows
us to self-host lld when --gc-sections is enabled. There are still quite a few problems
with --gc-sections (test failures), so the option can't be enabled by default.
Differential Revision: D7926
Reviewed by: ruiu, shankarke
llvm-svn: 230737
This reverts commit r230732.
sectionSize() in lib/Core/SymbolTable.cpp still depends on the layout-
after edges, so we couldn't remove them yet.
llvm-svn: 230734
Previously we needed to create atoms as a doubly-linked link, but it's
no longer needed. Also we don't use layout-after edges in PE/COFF.
Creating such edges is just waste.
llvm-svn: 230732
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
Previously we have a string -> string map to keep the weak alias
symbol mapping. Naturally we can't define more than one weak alias
with that data structure.
This patch is to allow multiple aliases for the same symbol by
changing the map type to string -> set of string map.
llvm-svn: 230702
In LLD's model, symbol is a property of the node (atom) and not a property of
edge (reference). Prior to this patch, we stored the symbol in the reference.
From post-commit comments, it seemed better to create a map from the reference
to the symbol instead and use this mapping wherever desired.
Address comments from Ruiu/Simon Atanasyan.
llvm-svn: 230273
SHF_GROUP: Group Member Sections
----------------------------------
A section which is part of a group, and is to be retained or discarded with the
group as a whole, is identified by a new section header attribute: SHF_GROUP
This section is a member (perhaps the only one) of a group of sections, and the
linker should retain or discard all or none of the members. This section must be
referenced in a SHT_GROUP section. This attribute flag may be set in any section
header, and no other modification or indication is made in the grouped sections.
All additional information is contained in the associated SHT_GROUP section.
SHT_GROUP: Section Group Definition
-------------------------------------
Represents a group section.
The section group's sh_link field identifies a symbol table section, and its
sh_info field the index of a symbol in that section. The name of that symbol is
treated as the identifier of the section group.
More information: https://mentorembedded.github.io/cxx-abi/abi/prop-72-comdat.html
Added a lot of extensive tests, that tests functionality.
llvm-svn: 230195
When the GNU linker sees two input sections with the same name, and the name
starts with ".gnu.linkonce.", the linker will only keep one copy and discard the
other. Any section whose name starts with “.gnu.linkonce.” is a COMDAT section.
Some architectures like Hexagon use this section to store floating point constants,
that need be deduped.
This patch adds gnu.linkonce functionality to the ELFReader.
llvm-svn: 230194
There is code(added by me) in the YAMLReader which isn't correct when it handles references
for section groups. The test case was also checking for wrong outputs.
This fixes the bug and the testcase so that they check for proper outputs.
llvm-svn: 230190
This is mainly for back-compatibility with GNU ld.
Ideally --stats should be a general option in LinkingContext, providing
individual stats for every pass in the linking process.
In the GNU driver, a better wording could be used, but there's no need
to change it for now.
Differential Revision: D7657
Reviewed by: ruiu
llvm-svn: 230157
Now since the correct file path for atoms is available and not clobbered,
commit r222309 which was reverted previously can be added back.
No change in functionality.
llvm-svn: 230138
Looks like there's a threading issue in the COFF reader which makes
buildbot unstable. Probability of crash varies depending on the number
of input. If we are linking a big executalbe, LLD almost always crash.
This patch temporarily adds a lock to guard the reader so that LLD
doesn't crash. I'll investigate and fix the issue as soon as possible
because this patch has negative performance impact.
llvm-svn: 230086
The round-trip passes were introduced in r193300. The intention of
the change was to make sure that LLD is capable of reading end
writing such file formats.
But that turned out to be yet another over-designed stuff that had
been slowing down everyday development.
The passes ran after the core linker and before the writer. If you
had an additional piece of information that needs to be passed from
front-end to the writer, you had to invent a way to save the data to
YAML/Native. These passes forced us to do that even if that data
was not needed to be represented neither in an object file nor in
an executable/DSO. It doesn't make sense. We don't need these passes.
http://reviews.llvm.org/D7480
llvm-svn: 230069
LinkerScript AST nodes are never destroyed which means that their
std::vector members will never be destroyed.
Instead, allocate the operand list itself in the Parser's
BumpPtrAllocator. This ensures that the storage will be destroyed along
with the nodes when the Parser is destroyed.
llvm-svn: 229967
This is yet another edge case of base relocation for symbols. Absolute
symbols are in general not target of base relocation because absolute
atom is a way to point to a specific memory location. In r229816, I
removed entries for absolute atoms from the base relocation table
(so that they won't be fixed by the loader).
However, there was one exception -- ImageBase. ImageBase points to the
start address of the current image in memory. That needs to be fixed up
at load time. This patch is to treat the symbol in a special manner.
llvm-svn: 229961
Previously we wrongly emitted a base relocation entry for an absolute symbol.
That made the loader to rewrite some instruction operands with wrong values
only when a DLL is not loaded at the default address. That caused a
misterious crash of some executable.
Absolute symbols will of course never change value wherever the binary is
loaded to memory. We shouldn't emit base relocations for absolute symbols.
llvm-svn: 229816
Weak aliases defined using /alternatename command line option were getting
wrong RVAs in the final output because of wrong atom ordinal. Alias atoms
were assigned large ordinals than any other regular atoms because they were
instantiated after other atoms and just got new (larger) ordinals.
Atoms are sorted by its file and atom ordinals in the order pass. Alias
atoms were located after all other atoms in the same file.
An alias atom's ordinal needs to be smaller than its alias target but larger
than the atom appeared before the target -- so that the alias is located
between the two. Since an alias has no size, the alias target will be located
at the same location as the alias.
In this patch, I made a gap between two regular atoms so that we can put
aliases after instantiating them (without re-numbering existing atoms).
llvm-svn: 229762
atomContent's memory is freed at the end of the stack frame,
but it is referenced by the atom pushed into _definedAtoms.
Differential Revision: http://reviews.llvm.org/D7732
llvm-svn: 229749
Summary:
Define an explicit type for arch specific reference kind and use it in switch statement to make the compiler emit warnings if some case is not cover.
It will help to catch such errors when we add new mach-o reference kind.
Reviewers: shankarke, kledzik
Reviewed By: shankarke
Subscribers: shankarke, aemerson, llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D7612
llvm-svn: 229246
Wrap functionality was using a std::set to record symbols that need to be
wrapped. This changes the implementation to use a StringSet instead.
No change in functionality.
llvm-svn: 229165
If the name field of a symbol table entry is all zero, it's interpreted
as it's pointing to the beginning of the string table. The first four
bytes of the string table is the size field, so dumpbin dumps that number
as an ASCIZ string.
This patch fills a dummy value to name field.
llvm-svn: 228971
Use a wrapper function for symbol. Any undefined reference to symbol will be
resolved to "__wrap_symbol". Any undefined reference to "__real_symbol" will be
resolved to symbol.
This can be used to provide a wrapper for a system function. The wrapper
function should be called "__wrap_symbol". If it wishes to call the system
function, it should call "__real_symbol".
Here is a trivial example:
void * __wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap malloc, then all calls
to "malloc" will call the function "__wrap_malloc" instead. The call to
"__real_malloc" in "__wrap_malloc" will call the real "malloc" function.
llvm-svn: 228906
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 dumpbin tool in the MSVC toolchain cannot handle an executable created
by LLD if the executable contains a long section name.
In PE/COFF, a section name is stored to a section table entry. Because the
section name field in the table is only 8 byte long, a name longer than
that is stored to the string table and the offset in the string table is
stored to the section table entry instead.
In order to look up a string from the string table, tools need to handle
the symbol table, because the string table is defined as it immediately
follows the symbol table.
And seems the dumpbin doesn't like zero-length symbol table.
This patch teaches LLD how to emit a dummy symbol table. The dummy table
has one dummy entry in it.
llvm-svn: 228900
When calling ARM code from Thumb and vice versa,
a veneer that switches instruction set should be generated.
Added veneer generation for ARM_JUMP24 ARM_THM_JUMP24 instructions.
Differential Revision: http://reviews.llvm.org/D7502
llvm-svn: 228680
After the total number of program headers are determined, virtual addresses
and file offsets need not be reassigned for sections whose virtual addresses and
fileoffsets remained the same.
This doesnot change any functionality.
llvm-svn: 228377
Only search library directories explicitly specified
on the command line. Library directories specified in linker
scripts (including linker scripts specified on the command
line) are ignored.
llvm-svn: 228375
Previously we only have File::path() to get the path name of a file.
If a file was a member of an archive file, path() returns a concatenated
string of the file name in the archive and the archive file name.
If we wanted to get a file name or an archive file name, we had to
parse that string. That's of course not good.
This patch adds new member functions, archivePath and memberPath, to File.
http://reviews.llvm.org/D7447
llvm-svn: 228352
The real user of the LayoutPass is now only Mach-O, so move that
pass out of the common directory to Mach-O directory.
"Core" architecture were using the LayoutPass. I modified that
to use a simple OrderPass. I think no one actually have authority
what feature should be in Core and what's not, but I believe the
LayoutPass is not very suitable for Core. Before more code starts
depending on the complex pass, it's better to remove that from
Core.
I could have simplified that pass because Mach-O is the only user
of the LayoutPass. For example, the second parameter of the
LayoutPass constructor can be converted from optional to mandatory.
I didn't do that in this patch to keep it simple. I'll do in a
followup patch.
http://reviews.llvm.org/D7311
llvm-svn: 228341
Previously, we incorrectly added the image base address to an absolute
symbol address (that calculation doesn't make any sense) if an
IMAGE_REL_I386_DIR32 relocation is applied to an absolute symbol.
This patch fixes the issue. With this fix, we can link Bochs using LLD.
(Choosing Bochs has no special meaining -- I just picked it up as a
test program and found it didn't work.) This also fixes one of the
issues we currently have to link Chromium using LLD.
llvm-svn: 228279
This may be a little bit inefficient than the original code
but that should be okay as this is not really in a performance
critical pass.
http://reviews.llvm.org/D7393
llvm-svn: 228077
INPUT directive is a variant of GROUP in the sense that that specifies
a list of input files. The only difference is whether the entire file
list is wrapped with a --start-group/--end-group or not.
http://reviews.llvm.org/D7390
llvm-svn: 228060
Currently, no one owns script::Parser buffers, but yet ELFLinkingContext gets
updated with StringRef pointers to data inside Parser buffers. Since this buffer
is locally owned inside GnuLdDriver::evalLinkerScript(), as soon as this
function finishes, all pointers in ELFLinkingContext that comes from linker
scripts get invalid. The problem is that we need someone to own linker scripts
data structures and, since ELFLinkingContext transports references to linker
scripts data, we can simply make it also own all linker scripts data.
Differential Revision: http://reviews.llvm.org/D7323
llvm-svn: 227975
Added relocations to perform function calls with and without passing arguments.
ARM-only, Thumb-only and mixed mode code generations are supported.
Only simple veneers (direct instruction modification) are supported as ARM-Thumb interwork.
Differential Revision: http://reviews.llvm.org/D7223
llvm-svn: 227961
Previously we applied the LayoutPass to order atoms and then
apply elf::ArrayOrderPass to sort them again. The first pass is
basically supposed to sort atoms in the normal fashion (which
is to sort symbols in the same order as the input files).
The second pass sorts atoms in {init,fini}_array.<priority> by
priority.
The problem is that the LayoutPass is overkill. It analyzes
references between atoms to make a decision how to sort them.
It's slow, hard to understand, and above all, it doesn't seem
that we need its feature for ELF in the first place.
This patch remove the LayoutPass from ELF pass list. Now all
reordering is done in elf::OrderPass. That pass sorts atoms by
{init,fini}_array, and if they are not in the special section,
they are ordered as the same order as they appear in the command
line. The new code is far easier to understand, faster, and
still able to create valid executables.
Unlike the previous layout pass, elf::OrderPass doesn't count
any attributes of an atom (e.g. permissions) except its
position. It's OK because the writer takes care of them if we
have to.
This patch changes the order of final output, although that's
benign. Tests are updated.
http://reviews.llvm.org/D7278
llvm-svn: 227666
The LayoutPass is one of the slowest pass. This change is to skip
that pass. This change not only improve performance but also improve
maintainability of the code because the LayoutPass is pretty complex.
Previously we used the LayoutPass to sort all atoms in a specific way,
and reorder them again for PE/COFF in GroupedSectionPass.
I spent time on improving and fixing bugs in the LayoutPass (e.g.
r193029), but the pass is still hard to understand and hard to use.
It's better not to depend on that if we don't need. For PE/COFF, we
just wanted to sort atoms in the same order as the file order in the
command line.
The feature we used in the LayoutPass is now simplified to
compareByPosition function in OrderPass.cpp. The function is just 5
lines.
This patch changes the order of final output because it changes the
sort order a bit. The output is still correct, though.
llvm-svn: 227500
That kind of reference was used only in ELFFile, and the use of
that reference there didn't seem to make sense. All test still
pass (after adjusting symbol names) without that code. LLD is
still be able to link LLD and Clang. Looks like we just don't
need this.
http://reviews.llvm.org/D7189
llvm-svn: 227259
Misread buildbot's log.
Both gcc and clang compile this fine.
Original fix reason:
gcc allows template specializations only in the same namespace
where template has been declared.
llvm-svn: 227183
Symbols addressing Thumb code have zero bit set in st_value to distinguish them from ARM instructions.
This caused wrong atoms' forming because of offset of one byte brought in by that corrected st_value.
Fixed reading of st_value & st_value-related things in ARMELFFile while forming atoms.
Symbol table generation is also fixed for Thumb atoms.
Differential Revision: http://reviews.llvm.org/D7161
llvm-svn: 227174
Anonymous atoms created there were getting wrong atom ordinal.
LayoutAfter references take precedence over atom ordinals, so
the bug was not visible, though.
llvm-svn: 227168
* Removed cyclic dependency between lldPECOFF and lldDriver
* Added missing dependencies in unit tests
Differential Revision: http://reviews.llvm.org/D7185
llvm-svn: 227134
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
The `Elf_Rel_Impl::setSymbolAndType` method now has the third argument
`IsMips64EL` (like complement methods `getSymbol` and `getType`). While
we do not support linking of MIPS64 ELF object file just pass `false`
to the `setSymbolAndType`.
llvm-svn: 227045
lldELF is used by each ELF backend. lldELF's ELFLinkingContext
also held a reference to each backend, creating a link-time
cycle. This patch moves the backend references to lldDriver.
Differential Revision: http://reviews.llvm.org/D7119
llvm-svn: 226976
Moved getMemoryBuffer from DarwnLdDriver to MachOLinkingContext.
lldMachO shared library target now builds.
Differential Review: http://reviews.llvm.org/D7155
llvm-svn: 226963
lldELF is used by each ELF backend. lldELF's ELFLinkingContext
also held a reference to each backend, creating a link-time
cycle. This patch moves the backend references to lldDriver.
Differential Revision: http://reviews.llvm.org/D7119
llvm-svn: 226922
Before this patch there was a cyclic dependency between lldCore and
lldReaderWriter. Only lldConfig could be built as a shared library.
* Moved Reader and Writer base classes into lldCore.
* The following shared libraries can now be built:
lldCore
lldYAML
lldNative
lldPasses
lldReaderWriter
Differential Revision: http://reviews.llvm.org/D7105
From: Greg Fitzgerald <garious@gmail.com>
llvm-svn: 226732
The code is able to statically link the simplest case of:
int main() { return 0; }
* Only works with ARM code - no Thumb code, no interwork (-marm -mno-thumb-interwork)
* musl libc built with no interwork and no Thumb code
Differential Revision: http://reviews.llvm.org/D6716
From: Denis Protivensky <dprotivensky@accesssoftek.com>
llvm-svn: 226643
The use of std::future introduces an implicit dependency on the PPL
subcomponent of ConcRT. ConcRT in general is pretty noisy with
warnings, so this patch just disables one of the noisy warnings.
llvm-svn: 226590
sh_addralign of zero is equivalent to sh_addralign of one, meaning
no alignment specified. Avoid calculating Log2 or modulus when
sh_addralign is zero as the results will not be useful.
llvm-svn: 226572
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
LLD parses archive file index table only at first. When it finds a symbol
it is looking for is defined in a member file in an archive file, it actually
reads the member from the archive file. That's done in the core linker.
That's a single-thread process since the core linker is single threaded.
If your command line contains a few object files and a lot of archive files
(which is quite often the case), LLD hardly utilizes hardware parallelism.
This patch improves parallelism by speculatively instantiating archive
file members. At the beginning of the core linking, we first create a map
containing all symbols defined in all members, and each time we find a
new undefined symbol, we instantiate a member file containing the
symbol (if such file exists). File instantiation is side effect free, so this
should not affect correctness.
This is a quick benchmark result. Time to link self-link LLD executable:
Linux 9.78s -> 8.50s (0.86x)
Windows 6.18s -> 4.51s (0.73x)
http://reviews.llvm.org/D7015
llvm-svn: 226336
Generalise the base relocation handling slightly to support multiple base
relocation types in PE/COFF. This is necessary to generate proper executables
for WoA.
Track the base relocation type from the decision that we need a base relocation
to the point where we emit the base relocation into base relocation directory.
Remove an outdated TODO item while in the area.
llvm-svn: 226335
We had such class there because of InputGraph abstraction.
Previously, no one except InputGraph itself has complete picture of
input file list. In order to create a set of all defined symbols,
we had to use some indirections there to workaround InputGraph.
It can now be rewritten as simple code. No change in functionality.
llvm-svn: 226319
This patch makes File::parse() multi-thread safe. If one thread is running
File::parse(), other threads will block if they try to call the same method.
File::parse() is idempotent, so you can safely call multiple times.
With this change, we don't have to wait for all worker threads to finish
in Driver::link(). Previously, Driver::link() calls TaskGroup::sync() to
wait for all threads running File::parse(). This was not ideal because
we couldn't start the resolver until we parse all files.
This patch increase parallelism by making Driver::link() to not wait for
worker threads. The resolver calls parse() to make sure that the file
being read has been parsed, and then uses the file. In this approach,
the resolver can run with the parser threads in parallel.
http://reviews.llvm.org/D6994
llvm-svn: 226281
The previous default behavior of LLD is --as-needed. LLD linked
against a DSO only if the DSO file was actually used to link an
executable (i.e. at least one symbol was resolved using the shared
library file.)
In this patch I added a boolean flag to FileNode for --as-needed.
I also added an accessor to DSO name to shared library file class.
llvm-svn: 226274
This class defines a relocation handler interface. The interface does
not depend on the template argument so the argument is redundant.
llvm-svn: 226259
The target may be a synthetic symbol like __ImageBase. cast_or_null will ensure
that the atom is a DefinedAtom, which is not guaranteed, which was the original
reason for the cast_or_null. Switch this to dyn_cast, which should enable
building of executables for WoA. Unfortunately, the issue of missing base
relocations still needs to be investigated.
llvm-svn: 226246
InputElement was named that because it's an element of an InputGraph.
It's losing the origin because the InputGraph is now being removed.
InputElement's subclass is FileNode, that naming inconsistency needed
to be fixed.
llvm-svn: 226147
They were the last member functions of InputGraph (besides members()).
Now InputGraph is just a container of a vector. We are ready to replace
InputGraph with plain File vector.
llvm-svn: 226146
These changes depended on r225674 and had been rolled back in r225859.
Because r225674 has been re-submitted, it's safe to re-submit them.
llvm-svn: 226132
The original commit had an issue with Mac OS dylib files. It didn't
handle fat binary dylib files correctly. This patch includes a fix.
A test for that case has already been committed in r225764.
llvm-svn: 226123
This is just a mechanical cleanup, no functionality changed. This just
fixes very minor inconsistencies with how #include lines were spaced and
sorted in LLD.
llvm-svn: 225978
r225764 broke a basic functionality on Mac OS. This change reverts
r225764, r225766, r225767, r225769, r225814, r225816, r225829, and r225832.
llvm-svn: 225859
PECOFF was the only user of the API, and the reason why we created
the API is because, although the driver creates a list of input files,
it has no knowledge on what files are being created. It was because
everything was hidden behind the InputGraph abstraction.
Now the driver knows what that's doing. We no longer need this
indirection to get the file list being processed.
llvm-svn: 225767
This is necessary to support linking a basic program which references symbols
outside of the module itself. Add the import thunk for ARM NT style imports.
This allows us to create the reference. However, it is still insufficient to
generate executables that will run due to base relocations not being emitted for
the import.
llvm-svn: 225428
This adds the ability to export symbols from a DLL built for ARMNT. Add this
support first to help work towards adding support for import thunks on Windows
on ARM. In order to generate the exports, add support for
IMAGE_REL_ARM_ADDR32NB relocations.
llvm-svn: 225339
ARM NT assumes a purely THUMB execution, and as such requires that the address
of entry point is adjusted to indicate a thumb entry point. Unconditionally
adjust the AddressOfEntryPoint in the PE header for PE/COFF ARM as we only
support ARM NT at the moment.
llvm-svn: 225139
ARM NT assumes a THUMB only environment. As such, any address that is detected
as residing in an executable section is adjusted to have its bottom bit set to
indicate THUMB in case of a mode exchange.
Although the testing here seems insufficient (missing the negative cases) the
existing test cases for the IMAGE_REL_ARM_{ADDR32,MOV32T} are relevant as they
ensure that we do not incorrectly set the bit.
llvm-svn: 225104
This adds support for IMAGE_REL_ARM_BRANCH24T relocations. Similar to the
IMAGE_REL_ARM_BLX32T relocation, this relocation requires munging an
instruction. The instruction encoding is quite similar, allowing us to reuse
the same munging implementation. This is needed by the entry point stubs for
modules provided by MSVCRT.
llvm-svn: 225082
This adds support for IMAGE_REL_ARM_BLX23T relocations. Similar to the
IMAGE_REL_ARM_MOV32T relocation, this relocation requires munging an
instruction. This inches us closer to supporting a basic hello world
application.
llvm-svn: 225081
This adds support for the IMAGE_REL_ARM_MOV32T relocation. This is one of the
most complicated relocations for the Window on ARM target. It involves
re-encoding an instruction to contain an immediate value which is the relocation
target.
llvm-svn: 225072
This implements the IMAGE_REL_ARM_ADDR32 relocation. There are still a few more
relocation types that need to resolved before lld can even attempt to link a
trivial program for Windows on ARM.
llvm-svn: 225057
This teaches lld about the ARM NT object types. Add a trivial test to ensure
that it can handle ARM NT object file inputs. It is still unable to perform the
necessary relocations for ARM NT, but this allows the linker to at least read
the objects.
llvm-svn: 225052
If a regular symbol has microMIPS-bit we need to stop linking. Now the
LLD does not check the `applyRelocation` return value and continues
linking anyway. As a temporary workaround use the `llvm_unreachable`
call to stop the linker.
llvm-svn: 224831
Summary:
Fix the binary file reader to properly read dyld version info.
Update the install_name test case to properly test the binary reader. We can't use '-print_atoms' as the output format is 'native' yaml and it does not contains the dyld current and compatibility versions.
Also change the timestamp value of LD_ID_DYLD to match the one generated by ld64.
The dynamic linker (dyld) used to expects different values for timestamp in LD_ID_DYLD and LD_LOAD_DYLD for prebound images. While prebinding is deprecated, we should probably keep it safe and match ld64.
Reviewers: kledzik
Subscribers: llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D6736
llvm-svn: 224681
Summary:
Work on adding -rpath support to the mach-o linker.
This patch is based on the ld64 behavior for the command line option validation.
It includes a basic test to check that the LC_RPATH load commands are properly generated when that option is used.
It also add LC_RPATH support to the binary reader, but I don't know how to test it though.
Reviewers: kledzik
Subscribers: llvm-commits
Projects: #lld
Differential Revision: http://reviews.llvm.org/D6724
llvm-svn: 224544
Rui Ueyama