summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/MachO/MachONormalizedFileBinaryReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [macho] -rpath supportJean-Daniel Dupas2014-12-181-0/+5
| | | | | | | | | | | | | | | | | | | | | 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
* Make File always take the ownership of a MemoryBuffer.Rui Ueyama2014-12-121-4/+4
| | | | | | | | | | | | | | The documentation of parseFile() said that "the resulting File object may take ownership of the MemoryBuffer." So, whether or not the ownership of a MemoryBuffer would be taken was not clear. A FileNode (a subclass of InputElement, which is being deprecated) keeps the ownership if a File doesn't take it. This patch makes File always take the ownership of a buffer. Buffers lifespan is not always the same as File instances. Files are able to deallocate buffers after parsing the contents. llvm-svn: 224113
* Separate file parsing from File's constructors.Rui Ueyama2014-12-121-15/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a second patch for InputGraph cleanup. Sorry about the size of the patch, but what I did in this patch is basically moving code from constructor to a new method, parse(), so the amount of new code is small. This has no change in functionality. We've discussed the issue that we have too many classes to represent a concept of "file". We have File subclasses that represent files read from disk. In addition to that, we have bunch of InputElement subclasses (that are part of InputGraph) that represent command line arguments for input file names. InputElement is a wrapper for File. InputElement has parseFile method. The method instantiates a File. The File's constructor reads a file from disk and parses that. Because parseFile method is called from multiple worker threads, file parsing is processed in parallel. In other words, one reason why we needed the wrapper classes is because a File would start reading a file as soon as it is instantiated. So, the reason why we have too many classes here is at least partly because of the design flaw of File class. Just like threads in a good threading library, we need to separate instantiation from "start" method, so that we can instantiate File objects when we need them (which should be very fast because it involves only one mmap() and no real file IO) and use them directly instead of the wrapper classes. Later, we call parse() on each file in parallel to let them do actual file IO. In this design, we can eliminate a reason to have the wrapper classes. In order to minimize the size of the patch, I didn't go so far as to replace the wrapper classes with File classes. The wrapper classes are still there. In this patch, we call parse() immediately after instantiating a File, so this really has no change in functionality. Eventually the call of parse() should be moved to Driver::link(). That'll be done in another patch. llvm-svn: 224102
* [mach-o] propagate dylib version numbersNick Kledzik2014-11-191-1/+3
| | | | | | | | | | | | | | Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead, the linker copies four things from each dylib to each client: the runtime path (aka "install name"), the build time, current version (dylib build number), and compatibility version The build time is no longer used (it cause every rebuild of a dylib to be different). The compatibility version is usually just 1.0 and never changes, or the dylib becomes incompatible. This patch copies that information into the NormalizedMachO format and propagates it to clients. llvm-svn: 222300
* Follow-up to r221913. Fix some -Wcast-qual warning reasons.Simon Atanasyan2014-11-141-6/+6
| | | | llvm-svn: 221974
* TMP: fix readN & writeN to not encourage UBTim Northover2014-10-271-79/+78
| | | | llvm-svn: 220730
* Sort include files according to convention.Shankar Easwaran2014-10-181-2/+0
| | | | llvm-svn: 220131
* [mach-o] Support fat archivesNick Kledzik2014-10-081-36/+44
| | | | | | | | | | | | | | 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
* [mach-o] Let darwin driver infer arch from .o files if -arch not used.Nick Kledzik2014-09-041-19/+54
| | | | | | | | | | | | | | | | 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
* [mach-o] Add support for using export triesNick Kledzik2014-09-031-1/+29
| | | | | | | | | | | On Darwin at runtime, dyld will prefer to use the export trie of a dylib instead of the traditional symbol table (which is large and requires a binary search). This change enables the linker to generate an export trie and to prefer it if found in a dylib being linked against. This also simples the yaml for dylibs because the yaml form of the trie can be reduced to just a sequence of names. llvm-svn: 217066
* [mach-o] Support re-exported dylibsNick Kledzik2014-08-131-13/+32
| | | | | | | | | | | | | | | | | | | | In general two-level namespace means each program records exactly which dylib each undefined (imported) symbol comes from. But, sometimes the implementor wants to hide the implementation dylib. For instance libSytem.dylib is the base dylib all Darwin programs must link with. A few years ago it was split up into two dozen dylibs by all are hidden behind libSystem.dylib which re-exports each sub-dylib. All clients still think libSystem.dylib is the implementor. To support this, the linker must load "indirect" dylibs and not just the "direct" dylibs specified on the command line. This is done in the createImplicitFiles() method after all command line specified files are loaded. Since an indirect dylib may have already been loaded as a direct dylib (or indirectly via a previous direct dylib), the MachOLinkingContext keeps a list of all loaded dylibs. With this change hello world can now be linked against the real OS or SDK. llvm-svn: 215605
* [mach-o] Add support for LC_DATA_IN_CODENick Kledzik2014-07-241-8/+21
| | | | | | | | | | | | | | 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
* [mach-o] refactor KindHandler into ArchHandler and simplify passes.Nick Kledzik2014-07-161-21/+7
| | | | | | | | | | | All architecture specific handling is now done in the appropriate ArchHandler subclass. The StubsPass and GOTPass have been simplified. All architecture specific variations in stubs are now encoded in a table which is vended by the current ArchHandler. llvm-svn: 213187
* [mach-o] add representation for LC_ID_DYLIB to MachONormalizedFileTim Northover2014-07-011-0/+9
| | | | | | | It still needs to be tied into BinaryReader, but this allows reasonably sensible creation of SharedLibrary atoms on MachO. llvm-svn: 212093
* [mach-o] improve errors when mixing architecturesNick Kledzik2014-06-301-18/+15
| | | | llvm-svn: 212072
* MachO: support atomization of dylibs.Tim Northover2014-06-301-1/+2
| | | | | | | For .dylib files, we refrain from actually creating any atoms until they're requested via the "exports" method. llvm-svn: 212027
* [mach-o] refactor x86_64 relocation handling.Nick Kledzik2014-06-271-1/+1
| | | | | | | | | | | | | | This is first step in reworking how mach-o relocations are processed. The existing KindHandler is going to become a delgate/helper object for processing architecture specific references. The KindHandler knows how to convert mach-o relocations into References and back, as well, as fixing up the content the relocation is on. One of the messy things about mach-o relocations is that they sometime come in pairs, but the pairs still convert to one lld::Reference. So, the conversion has to detect pairs (arch specific) and change the stride. llvm-svn: 211921
* Using llvm::sys::swapByteOrder() for the common case of byte-swapping a ↵Artyom Skrobov2014-06-141-5/+7
| | | | | | value in place llvm-svn: 210979
* Left two files out of the previous commitArtyom Skrobov2014-06-141-3/+3
| | | | llvm-svn: 210975
* Update for llvm api change.Rafael Espindola2014-06-131-8/+9
| | | | llvm-svn: 210919
* include system_error directly.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210801
* Run llvm/utils/sort_includes.py in a few files.Rafael Espindola2014-06-121-3/+0
| | | | | | This will reduce the noise in a followup patch. llvm-svn: 210800
* Don't import error_code into the lld namespace.Rafael Espindola2014-06-121-20/+19
| | | | llvm-svn: 210785
* Don't use make_error_code from the llvm namespace.Rafael Espindola2014-06-121-8/+8
| | | | llvm-svn: 210741
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-111-8/+8
| | | | | | This is an update for a llvm api change. llvm-svn: 210689
* This lambda returns a boolean, update the return statements.Rafael Espindola2014-06-031-7/+7
| | | | llvm-svn: 210071
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-311-5/+5
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209948
* [mach-o] Wire up mach-o binary reader to reader registryNick Kledzik2014-05-301-0/+48
| | | | llvm-svn: 209868
* [mach-o] Support parsing of non-lazy-pointer sectionsNick Kledzik2014-05-281-4/+49
| | | | llvm-svn: 209704
* Fix trailing whitespace.Shankar Easwaran2014-01-271-29/+29
| | | | llvm-svn: 200182
* [MachO] Begin support for reading fat binaries.Joey Gouly2014-01-141-21/+57
| | | | llvm-svn: 199259
* [mach-o] enable mach-o and native yaml to be intermixedNick Kledzik2014-01-111-4/+6
| | | | | | | | | | | | | | | | | | 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
* Run clang-format on r197727.Rui Ueyama2013-12-201-6/+3
| | | | llvm-svn: 197788
* [lld] Introduce registry and Reference kind tupleNick Kledzik2013-12-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [mach-o] binary reader and writer Nick Kledzik2013-11-061-0/+310
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
OpenPOWER on IntegriCloud