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
Looks like there's a race condition around here that caused LLD to crash
on Windows. Currently we are parsing libraries specified by .drectve section
asynchronously, and something is wrong in that process. Disable the feature
for now to make buildbots happy.
llvm-svn: 228955
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
We used to do like this instead of putting all command line processing
code within one gigantic switch statement. It is converted to a switch
in r188958, which introduced InputGraph.
In this patch I roll that change back. Now all "break"s are removed,
and the nesting is one level shallow.
llvm-svn: 228646
The values are already arranged in ascending order, and all tests still pass.
Removing the values as its confusing when new enumerations need to be added.
llvm-svn: 228381
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
Use the environment variable "LLD_RUN_ROUNDTRIP_TEST" in the test that you want
to disable, as
RUN: env LLD_RUN_ROUNDTRIP_TEST= <run>
This was a patch that I made, but I find this a better way to accomplish what we
want to do.
llvm-svn: 228376
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
This caused some tests to fail on FreeBSD, and Mac OS X.
Some std::sort() implementations will check for strict-weak-ordering
by comparing with the same element, or will compare an element to
itself for 1-element sequence. Take care of this case. Thanks to
chandlerc for explaning that to me.
Reviewed by: ruiu
llvm-svn: 227709
This is needed, among others by the FreeBSD kernel linker script.
Patch by Davide Italiano!
Reviewers: ruiu, rafaelauler
Differential Revision: http://reviews.llvm.org/D7220
llvm-svn: 227694
These fields were made protected in r193585. The aim of that change is to
expose these fields to SimpleFileWrapper. Because SimpleFileWrapper class
was removed in r227549, we can make them private.
llvm-svn: 227672
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
SimpleFileWrapper was a class to wrap an existing (possibly non-mutable)
file as a mutable file. We used instances of the class in RoundTrip*
passes, because the passes convert mutable files to non-mutable files,
and we needed to convert them back to mutable.
That feature can be implemented without defining a new class. Generally
speaking, if we can implement a feature without defining a class and
using only public interface of exsiting classes, that's preferred way
to do that. And this is the case.
llvm-svn: 227549
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
Time to link lld using lld improved from 5.7s to 5.4s on Windows.
It's not a significant improvement but not bad for one-line change.
This patch includes a bug fix for Parallel.h as the original code
uses operator< instead of a compare function there.
llvm-svn: 227132
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
I believe the original code is valid, but on Windows it failed with an
assertion error saying "Expression: vector iterator is not decrementable."
Don't use rbegin and rend to workaround that error.
llvm-svn: 226706
yaml2obj command ran by this test took more than 15 seconds to finish
because of extremely large .bss section. Other tests only takes 3 seconds.
Reduce the size to make it faster.
llvm-svn: 226693
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
We used to manage the state whether we are in a group or not
using a counter. The counter is incremented by one if we jump from
end-group to start-group, and decremented by one if we don't.
The counter was assumed to be either zero or one, but obviously it
could be negative (if there's a group which is not repeated at all).
This is a fix for that issue.
llvm-svn: 226632
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
The member function was defined to allow subclasses to customize
error message. But since we only have one FileNode type, there's
no actual need for that.
llvm-svn: 226139
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
getNextFile used to have a complex logic to determine which file
should be processed by the Resolver on next iteration.
Now, it is just a sequential accessor to the internal array and
provides no sensible feature.
This patch also removes InputGraph::getGroupSize and InputGraph::
skipGroup to simplify the code.
llvm-svn: 225832
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
Instead of representing a linker script file as an "InputElement",
parse and evaluate scripts in the driver as we see them.
Linker scripts are not regular input files (regular file is one of
object, archive, or shared library file). They are more like
extended command line options. Linker script handling was needlessly
complicated because of that inappropriate abstraction (besides
excessive class hierarchy -- there is no such thing like ELF linker
script but we had two classes there for some reason.)
LinkerScript was one of a few remaining InputElement subclasses
that can be expanded to multiple files. With this patch, we are one
step closer to retire InputElement.
http://reviews.llvm.org/D6648
llvm-svn: 225330
This is a part of InputGraph cleanup to represent input files as a flat
list of Files (and some meta-nodes for group etc.)
We cannot achieve that goal in one gigantic patch, so I split the task
into small steps as shown below.
(Recap the progress so far: Currently InputGraph contains a list of
InputElements. Each InputElement contain one File (that used to have
multiple Files, but I eliminated that use case in r223867). Files are
currently instantiated in Driver::link(), but I already made a change
to separate file parsing from object instantiation (r224102), so we
can safely instantiate Files when we need them, instead of wrapping
a file with the wrapper class (FileNode class). InputGraph used to
act like a generator class by interpreting groups by itself, but it's
now just a container of a list of InputElements (r223867).)
1. Instantiate Files in the driver and wrap them with WrapperNode.
WrapperNode is a temporary class that allows us to instantiate Files
in the driver while keep using the current InputGraph data structure.
This patch demonstrates how this step 1 looks like, using Core driver
as an example.
2. Do the same thing for the other drivers.
When step 2 is done, an InputGraph consists of GroupEnd objects or
WrapperNodes each of which contains one File. Other types of
FileNode subclasses are removed.
3. Replace InputGraph with std::vector<std::unique_ptr<InputElement>>.
InputGraph is already just a container of list of InputElements,
so this step removes that needless class.
4. Remove WrapperNode.
We need some code cleanup between each step, because many classes
do a bit odd things (e.g. InputGraph::getGroupSize()). I'll straight
things up as I need to.
llvm-svn: 225313
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
Correct the yaml definition for the object. Adjust the symbol storage class
which was flipped for the two symbols, resulting in the link failure due to the
symbol missing. Adjust the virtual address of the section. This ripples into
the test case, since the data has been shifted up by 4 bytes.
llvm-svn: 225058
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
strings don't mix so easily. This fixes the last remaining failure
I have in 'check-all' on a system with both Python3 and and Python2
installed.
llvm-svn: 224947
allows it to support multilib suffixed hosts using lib64, etc. This
variable is now available both in the direct LLVM build and from the
LLVMConfig.cmake file used by standalone builds.
llvm-svn: 224925
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
The LLD output in the YAML mode depends on LLD_RUN_ROUNDTRIP_TEST
environment variable. Do not check unimportant YAML items like section-name.
llvm-svn: 224830
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
ReaderErrorCategory was used only at one place. We now have a
DynamicErrorCategory for this kind of one-time error, so use it.
The calling function doesn't really care the type of an error, so
ReaderErrorCategory was actually dead code.
llvm-svn: 224245
These member functions returns either no_more_files error or a File object.
We could simply return a nullptr instead of a no_more_files.
This function will be removed soon as a part of InputGraph cleanup.
I had to do that step by step.
llvm-svn: 224208
Simon Atanasyan