aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/SymbolicFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-10-11Convert the last uses of ErrorOr in include/llvm/Object.Rafael Espindola1-2/+4
llvm-svn: 315483
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-30/+32
This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-1/+1
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-04-19[Object] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-3/+11
other minor fixes (NFC). llvm-svn: 300779
2016-11-30[WebAssembly] Add llvm-objdump support for wasm file formatDerek Schuff1-0/+1
This is the first part of an effort to add wasm binary support across all llvm tools. Patch by Sam Clegg Differential Revision: https://reviews.llvm.org/D26172 llvm-svn: 288251
2016-11-15Fix -Wswitch.Rui Ueyama1-0/+1
llvm-svn: 286920
2016-11-13Bitcode: Change module reader functions to return an llvm::Expected.Peter Collingbourne1-4/+4
Differential Revision: https://reviews.llvm.org/D26562 llvm-svn: 286752
2016-08-17Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner1-1/+1
This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
2016-04-06Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby1-7/+7
to produce a real error message Produce the first specific error message for a malformed Mach-O file describing the problem instead of the generic message for object_error::parse_failed of "Invalid data was encountered while parsing the file”.  Many more good error messages will follow after this first one. This is built on Lang Hames’ great work of adding the ’Error' class for structured error handling and threading Error through MachOObjectFile construction. And making createMachOObjectFile return Expected<...> . So to to get the error to the llvm-obdump tool, I changed the stack of these methods to also return Expected<...> : object::ObjectFile::createObjectFile() object::SymbolicFile::createSymbolicFile() object::createBinary() Then finally in ParseInputMachO() in MachODump.cpp the error can be reported and the specific error message can be printed in llvm-objdump and can be seen in the existing test case for the existing malformed binary but with the updated error message. Converting these interfaces to Expected<> from ErrorOr<> does involve touching a number of places. To contain the changes for now use of errorToErrorCode() and errorOrToExpected() are used where the callers are yet to be converted. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values. So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(ObjOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 265606
2015-08-28Re-apply r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama1-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
2015-08-28Rollback r246276 - Object: Teach llvm-ar to create symbol table for COFF ↵Rui Ueyama1-46/+1
short import files This change caused a test for llvm-readobj to fail. llvm-svn: 246277
2015-08-28Object: Teach llvm-ar to create symbol table for COFF short import files.Rui Ueyama1-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
2015-02-25Object: Handle Mach-O kext bundle filesJustin Bogner1-0/+1
This particular subtype of Mach-O was missing. Add it. llvm-svn: 230567
2014-12-09Rename createIRObjectFile to just create.Rafael Espindola1-2/+2
It is a static method of IRObjectFile, so having to use IRObjectFile::createIRObjectFile was redundant. llvm-svn: 223822
2014-11-18Support ELF files of unknown type.Michael J. Spencer1-0/+1
llvm-svn: 222208
2014-09-18LTO: introduce object file-based on-disk module format.Peter Collingbourne1-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
2014-09-03unique_ptrify IRObjectFile::createIRObjectFileDavid Blaikie1-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
2014-09-03Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type.David Blaikie1-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
2014-08-19Don't own the buffer in object::Binary.Rafael Espindola1-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
2014-07-31Use std::unique_ptr to make the ownership explicit.Rafael Espindola1-1/+1
llvm-svn: 214377
2014-06-24Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola1-3/+4
Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
2014-06-23Pass a std::unique_ptr& to the create??? methods is lib/Object.Rafael Espindola1-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
2014-06-23Make ObjectFile and BitcodeReader always own the MemoryBuffer.Rafael Espindola1-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
2014-02-21Add a SymbolicFile interface between Binary and ObjectFile.Rafael Espindola1-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
generated by cgit v1.1 at 2025-10-04 02:50:42 +0000