summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object/SymbolicFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-281-1/+4
| | | | | | | | | | | short import files This patch includes a fix for a llvm-readobj test. With this patch, the tool does no longer print out COFF headers for the short import file, but that's probably desirable because the header for the short import file is dummy. llvm-svn: 246283
* Rollback r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama2015-08-281-46/+1
| | | | | | | | short import files This change caused a test for llvm-readobj to fail. llvm-svn: 246277
* Object: Teach llvm-ar to create symbol table for COFF short import files.Rui Ueyama2015-08-281-1/+46
| | | | | | | | | | | | | COFF short import files are special kind of files that contains only DLL-exported symbol names. That's different from object files because it has no data except symbol names. This change implements a SymbolicFile interface for the short import files so that symbol names can be accessed through that interface. llvm-ar is now able to read the file and create symbol table entries for short import files. llvm-svn: 246276
* 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