This results in some simplifications to the code where an OwningPtr had to
be used with the previous api and then ownership moved to a unique_ptr for
the rest of lld.
llvm-svn: 203809
This restores the debug output to how it was before r197727 broke it. This
went undetected because the corresponding test was never run due to broken
feature detection.
llvm-svn: 202079
The main goal of this patch is to allow "mach-o encoded as yaml" and "native
encoded as yaml" documents to be intermixed. They are distinguished via
yaml tags at the start of the document. This will enable all mach-o test cases
to be written using yaml instead of checking in object files.
The Registry was extend to allow yaml tag handlers to be registered. The
mach-o Reader adds a yaml tag handler for the tag "!mach-o".
Additionally, this patch fixes some buffer ownership issues. When parsing
mach-o binaries, the mach-o atoms can have pointers back into the memory
mapped .o file. But with yaml encoded mach-o, name and content are ephemeral,
so a copyRefs parameter was added to cause the mach-o atoms to make their
own copy.
llvm-svn: 198986
It will configure resonable defaults for other settings in the
MachOLinkingContext object based on the parameters.
Patch by Joe Ranieri
llvm-svn: 197851
The main changes are in:
include/lld/Core/Reference.h
include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.
1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers. It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.
The new model is that there is a global Registry object. You programmatically
register the Readers you want with the registry object. Whenever you need to
read/parse a file, you ask the registry to do it, and the registry tries each
registered reader.
For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object.
2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings. Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values. The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value. This tuple system allows conversion to and from strings with
no ambiguities.
llvm-svn: 197727
This patch adds support for converting normalized mach-o to and from binary
mach-o. It also changes WriterMachO (which previously directly wrote a
mach-o binary given a set of Atoms) to instead do it in two steps. The first
step uses normalizedFromAtoms() to convert Atoms to normalized mach-o, and the
second step uses writeBinary() which to generate the mach-o binary file.
llvm-svn: 194167
n_desc field in MachO string table was not initialized. On Unix,
test/darwin/hello-world.objtxt did not fail because I think an nlist object
is always allocated to a fresh heap initialized with zeros. On Windows,
uninitialized fields are filled with 0xCC when compiled with /GZ. Because
of that the test was failing on Windows.
llvm-svn: 193909
Enable this for the following flavors
a) core
b) gnu
c) darwin
Its disabled for the flavor PECOFF. Convenient markers are added with FIXME
comments in the Driver that would be removed and code removed from each flavor.
llvm-svn: 193585
On discussing this with Nick, it looks like the StubAtoms
that contain a lazyImmediate reference kind should be null
and the location needs to be fixed up later with some value
that is an offset into the __LINKEDIT segment.
The drawback is that it allows yaml files with references
that expect a target to be considered without one.
This results in bad yaml files that would need to be handled
in the YAML Reader.
Inorder to fix this, the Stub Atoms use a dummy target such
as itself.
llvm-svn: 193476
This is the first step in how I plan to get mach-o object files support into
lld. We need to be able to test the mach-o Reader and Write on systems without
a mach-o tools. Therefore, we want to support a textual way (YAML) to represent
mach-o files.
MachONormalizedFile.h defines an in-memory abstraction of the content of mach-o
files. The in-memory data structures are always native endianess and always
use 64-bit sizes. That internal data structure can then be converted to or
from three different formats: 1) yaml (text) encoded mach-o, 2) binary mach-o
files, 3) lld Atoms.
This patch defines the internal model and uses YAML I/O to implement the
conversion to and from the model to yaml. The next patch will implement
the conversion from normalized to binary mach-o.
This patch includes unit tests to validate the yaml conversion APIs.
llvm-svn: 192147
Changes :-
a) Functionality in InputGraph to insert Input elements at any position
b) Functionality in the Resolver to use nextFile
c) Move the functionality of assigning file ordinals to InputGraph
d) Changes all inputs to MemoryBuffers
e) Remove LinkerInput, InputFiles, ReaderArchive
llvm-svn: 192081
This patch inverts the return value of these functions, so that they return
"true" on success and "false" on failure. The meaning of boolean return value
was mixed in LLD; for example, InputGraph::validate() returns true on success.
With this patch they'll become consistent.
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1748
llvm-svn: 191341
Also change some local variable names: "ti" -> "context" and
"_targetInfo" -> "_context".
Differential Revision: http://llvm-reviews.chandlerc.com/D1301
llvm-svn: 187823
The yaml reader is not specific to any file format. This patch moves
it to TargetInfo and makes validate a non virtual interface so that it
can be constructed from a single location.
The same method will be used to create a reader for llvm bitcode
files.
llvm-svn: 183740
The major changes are:
1) LinkerOptions has been merged into TargetInfo
2) LinkerInvocation has been merged into Driver
3) Drivers no longer convert arguments into an intermediate (core) argument
list, but instead create a TargetInfo object and call setter methods on
it. This is only how in-process linking would work. That is, you can
programmatically set up a TargetInfo object which controls the linking.
4) Lots of tweaks to test suite to work with driver changes
5) Add the DarwinDriver
6) I heavily doxygen commented TargetInfo.h
Things to do after this patch is committed:
a) Consider renaming TargetInfo, given its new roll.
b) Consider pulling the list of input files out of TargetInfo. This will
enable in-process clients to create one TargetInfo the re-use it with
different input file lists.
c) Work out a way for Drivers to format the warnings and error done in
core linking.
llvm-svn: 178776
I really would have liked to split this patch up, but it would greatly
complicate the lld-core and lld drivers having to deal with both
{Reader,Writer}Option and TargetInfo.
llvm-svn: 173217
table header. Skeleton code for ReferenceKinds.
Credits:
Doxygen by Michael Spencer.
Origianl implementation from Macho by Sidney Manning.
Templatization, implementation of section header chunks, string table, ELF header by Hemant Kulkarni.
llvm-svn: 163906
Although the code is not valid to begin with. It is trying to do a raw memory
copy of a non standard-layout type. nameoffset is not guaranteed to directly
follow cmdsize.
This should be properly fixed.
llvm-svn: 158612
ivars in WriterOptionsMachO instead have its methods compute ivar interactions.
Refactor mach-o Reference Kinds and introduce abstract class KindHandler.
Split up StubAtoms.hpp by architecture. Add support for 32-bit x86 stubs.
llvm-svn: 158336
now Reader and Writer subclasses for each file format. Each Reader and
Writer subclass defines an "options" class which controls how that Reader
or Writer operates.
llvm-svn: 157774
David Majnemer