Commit Graph

11 Commits

Author SHA1 Message Date
Joey Gouly 41cb030b53 [MachO] Add some missing NListTypes.
llvm-svn: 198468
2014-01-04 01:22:05 +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
Joey Gouly 53c99b78a8 Fix a gcc-4.8 warning, about extraneous semicolons.
llvm-svn: 198091
2013-12-28 00:46:57 +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
Nick Kledzik e34182f396 [mach-o] binary reader and writer
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
2013-11-06 21:36:55 +00:00
Rui Ueyama c1800beb55 Remove unnecessary namespace qualifier.
llvm-svn: 194037
2013-11-05 01:37:40 +00:00
Nick Kledzik 2453a3d956 Bug 17569: add namespaces to work with gcc-4.7
llvm-svn: 192627
2013-10-14 21:24:48 +00:00
Rui Ueyama c6015f6476 Update error classes from all lowercase to camel case.
llvm-svn: 192261
2013-10-09 00:57:22 +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