Commit Graph

19 Commits

Author SHA1 Message Date
Shankar Easwaran 2b67fca033 Sort include files according to convention.
llvm-svn: 220131
2014-10-18 05:33:55 +00:00
Nick Kledzik 14b5d208cb [mach-o] Support fat archives
mach-o supports "fat" files which are a header/table-of-contents followed by a
concatenation of mach-o files (or archives of mach-o files) built for
different architectures.  Previously, the support for fat files was in the
MachOReader, but that only supported fat .o files and dylibs (not archives).

The fix is to put the fat handing into MachOFileNode.  That way any input file
kind (including archives) can be fat.  MachOFileNode selects the sub-range
of the fat file that matches the arch being linked and creates a MemoryBuffer
for just that subrange.

llvm-svn: 219268
2014-10-08 01:48:10 +00:00
Nick Kledzik 1bebb2832e [mach-o] Add support for arm64 (AAarch64)
Most of the changes are in the new file ArchHandler_arm64.cpp.  But a few
things had to be fixed to support 16KB pages (instead of 4KB) which iOS arm64
requires.  In addition the StubInfo struct had to be expanded because
arm64 uses two instruction (ADRP/LDR) to load a global which requires two
relocations.  The other mach-o arches just needed one relocation.

llvm-svn: 217469
2014-09-09 23:52:59 +00:00
Nick Kledzik 635f9c7158 [mach-o] Let darwin driver infer arch from .o files if -arch not used.
Mach-O has a "fat" (or "universal") variant where the same contents built for
different architectures are concatenated into one file with a table-of-contents
header at the start.  But this leaves a dilemma for the linker - which
architecture to use.

Normally, the linker command line -arch is used to force which slice of any fat
files are used.  The clang compiler always passes -arch to the linker when
invoking it.  But some Makefiles invoke the linker directly and don’t specify
the -arch option.  For those cases, the linker scans all input files in command
line order and finds the first non-fat object file.  Whatever architecture it
is becomes the architecture for the link.

llvm-svn: 217189
2014-09-04 20:08:30 +00:00
Nick Kledzik 21921375cc [mach-o] Add support for LC_DATA_IN_CODE
Sometimes compilers emit data into code sections (e.g. constant pools or
jump tables). These runs of data can throw off disassemblers.  The solution
in mach-o is that ranges of data-in-code are encoded into a table pointed to
by the LC_DATA_IN_CODE load command.

The way the data-in-code information is encoded into lld's Atom model is that
that start and end of each data run is marked with a Reference whose offset
is the start/end of the data run.  For arm, the switch back to code also marks
whether it is thumb or arm code.

llvm-svn: 213901
2014-07-24 23:06:56 +00:00
Nick Kledzik 378066c80e [mach-o] improve errors when mixing architectures
llvm-svn: 212072
2014-06-30 22:57:33 +00:00
Rafael Espindola b1a4d3a26c Don't import error_code into the lld namespace.
llvm-svn: 210785
2014-06-12 14:53:47 +00:00
Rui Ueyama bc69bce7de [MachO] Remove "virtual" and add "override".
llvm-svn: 205057
2014-03-28 21:36:33 +00:00
Alexey Samsonov 8e6829e436 Remove extra semicolon for -Wpedantic
llvm-svn: 204219
2014-03-19 09:38:31 +00:00
Shankar Easwaran 3d8de47f76 Fix trailing whitespace.
llvm-svn: 200182
2014-01-27 03:09:26 +00:00
Joey Gouly 010b37691d [MachO] Begin support for reading fat binaries.
llvm-svn: 199259
2014-01-14 22:32:38 +00:00
Nick Kledzik 6edd722a2c [mach-o] enable mach-o and native yaml to be intermixed
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
2014-01-11 01:07:43 +00:00
Joey Gouly ceb16dedef [MachO] Begin to add some MachO specific File/Atoms, and add the start of
normalizedToAtoms.

llvm-svn: 198459
2014-01-03 23:12:02 +00:00
Rui Ueyama 170a1a892e Run clang-format on r197727.
llvm-svn: 197788
2013-12-20 07:48:29 +00:00
Nick Kledzik e555277780 [lld] Introduce registry and Reference kind tuple
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
2013-12-19 21:58:00 +00:00
Rui Ueyama 014192dbda Fix include guards.
llvm-svn: 194776
2013-11-15 03:09:26 +00:00
Rui Ueyama c1800beb55 Remove unnecessary namespace qualifier.
llvm-svn: 194037
2013-11-05 01:37:40 +00:00
Nick Kledzik 369ffd1c55 fix typos
llvm-svn: 192154
2013-10-08 02:07:19 +00:00
Nick Kledzik 30332b19d3 Supoort mach-o encoded in yaml.
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
2013-10-08 00:43:34 +00:00