summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object/SymbolicFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Object: Handle Mach-O kext bundle filesJustin Bogner2015-02-251-0/+1
| | | | | | This particular subtype of Mach-O was missing. Add it. llvm-svn: 230567
* Rename createIRObjectFile to just create.Rafael Espindola2014-12-091-2/+2
| | | | | | | It is a static method of IRObjectFile, so having to use IRObjectFile::createIRObjectFile was redundant. llvm-svn: 223822
* Support ELF files of unknown type.Michael J. Spencer2014-11-181-0/+1
| | | | llvm-svn: 222208
* LTO: introduce object file-based on-disk module format.Peter Collingbourne2014-09-181-3/+17
| | | | | | | | | | | | | | | | | | This format is simply a regular object file with the bitcode stored in a section named ".llvmbc", plus any number of other (non-allocated) sections. One immediate use case for this is to accommodate compilation processes which expect the object file to contain metadata in non-allocated sections, such as the ".go_export" section used by some Go compilers [1], although I imagine that in the future we could consider compiling parts of the module (such as large non-inlinable functions) directly into the object file to improve LTO efficiency. [1] http://golang.org/doc/install/gccgo#Imports Differential Revision: http://reviews.llvm.org/D4371 llvm-svn: 218078
* unique_ptrify IRObjectFile::createIRObjectFileDavid Blaikie2014-09-031-2/+1
| | | | | | | | I took a guess at the changes to the gold plugin, because that doesn't seem to build by default for me. Not sure what dependencies I might be missing for that. llvm-svn: 217056
* Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.David Blaikie2014-09-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | An unpleasant surprise while migrating unique_ptrs (see changes in lib/Object): ErrorOr<int*> was implicitly convertible to ErrorOr<std::unique_ptr<int>>. Keep the explicit conversions otherwise it's a pain to convert ErrorOr<int*> to ErrorOr<std::unique_ptr<int>>. I'm not sure if there should be more SFINAE on those explicit ctors (I could check if !is_convertible && is_constructible, but since the ctor has to be called explicitly I don't think there's any need to disable them when !is_constructible - they'll just fail anyway. It's the converting ctors that can create interesting ambiguities without proper SFINAE). I had to SFINAE the explicit ones because otherwise they'd be ambiguous with the implicit ones in an explicit context, so far as I could tell. The converting assignment operators seemed unnecessary (and similarly buggy/dangerous) - just rely on the converting ctors to convert to the right type for assignment instead. llvm-svn: 217048
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Use std::unique_ptr to make the ownership explicit.Rafael Espindola2014-07-311-1/+1
| | | | llvm-svn: 214377
* Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola2014-06-241-3/+4
| | | | | | | Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
* Pass a std::unique_ptr& to the create??? methods is lib/Object.Rafael Espindola2014-06-231-2/+3
| | | | | | | | This makes the buffer ownership on error conditions very natural. The buffer is only moved out of the argument if an object is constructed that now owns the buffer. llvm-svn: 211546
* Make ObjectFile and BitcodeReader always own the MemoryBuffer.Rafael Espindola2014-06-231-9/+5
| | | | | | | | | | This allows us to just use a std::unique_ptr to store the pointer to the buffer. The flip side is that they have to support releasing the buffer back to the caller. Overall this looks like a more efficient and less brittle api. llvm-svn: 211542
* Add a SymbolicFile interface between Binary and ObjectFile.Rafael Espindola2014-02-211-0/+67
This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
OpenPOWER on IntegriCloud