aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ObjectFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-09-19Allow public Triple deduction from ObjectFiles.Vlad Tsyrklevich1-0/+25
Move logic that allows for Triple deduction from an ObjectFile object out of llvm-objdump.cpp into a public factory, found in the ObjectFile class. This should allow other tools in the future to use this logic without reimplementation. Patch by Mitch Phillips Differential Revision: https://reviews.llvm.org/D37719 llvm-svn: 313605
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-29/+30
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-1/+4
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-15Add a file magic for CL.exe's object file created with /GL.Rui Ueyama1-0/+1
This patch makes it possible to identify object files created by CL.exe with /GL option. Such file contains Microsoft proprietary intermediate code instead of target machine code to do LTO. I need this to print out user-friendly error message from LLD. Differential Revision: https://reviews.llvm.org/D26645 llvm-svn: 286919
2016-10-18Object: Add a missing return in ObjectFile::createObjectFileJustin Bogner1-2/+2
When Error was threaded through these APIs back in r265606 the "return" was missed here, which triggers a warning if/when I add LLVM_NODISCARD to the Error type. llvm-svn: 284454
2016-05-02Thread Expected<...> up from libObject’s getType() for symbols to allow ↵Kevin Enderby1-2/+5
llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
2016-04-20Thread Expected<...> up from libObject’s getName() for symbols to allow ↵Kevin Enderby1-3/+3
llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . 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(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld 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: 266919
2016-04-06Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby1-10/+10
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
2016-03-25[Object] Make createMachOObjectFile return Expected<...> rather thanLang Hames1-1/+1
ErrorOr<...>. llvm-svn: 264473
2016-02-29Rename embedded bitcode section in MachOSteven Wu1-0/+7
Summary: Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode". The new name matches MachO section naming convention. Reviewers: rafael, pcc Subscribers: davide, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D17388 llvm-svn: 262245
2015-08-07Convert getSymbolSection to return an ErrorOr.Rafael Espindola1-3/+3
This function can actually fail since the symbol contains an index to the section and that can be invalid. llvm-svn: 244375
2015-07-07Delete UnknownAddress. It is a perfectly valid symbol value.Rafael Espindola1-0/+9
getSymbolValue now returns a value that in convenient for most callers: * 0 for undefined * symbol size for common symbols * offset/address for symbols the rest Code that needs something more specific can check getSymbolFlags. llvm-svn: 241605
2015-07-02Return ErrorOr from SymbolRef::getName.Rafael Espindola1-3/+3
This function can really fail since the string table offset can be out of bounds. Using ErrorOr makes sure the error is checked. Hopefully a lot of the boilerplate code in tools/* can go away once we have a diagnostic manager in Object. llvm-svn: 241297
2015-06-30Implement containsSymbol with other lower level methods.Rafael Espindola1-0/+7
llvm-svn: 241112
2015-06-09Remove object_error::success and use std::error_code() insteadRui Ueyama1-1/+1
make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
2015-05-31Simplify interface of function that doesn't fail.Rafael Espindola1-5/+1
llvm-svn: 238700
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-11-18Support ELF files of unknown type.Michael J. Spencer1-0/+1
llvm-svn: 222208
2014-08-19Don't own the buffer in object::Binary.Rafael Espindola1-8/+16
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-2/+5
llvm-svn: 214377
2014-07-06Update the MemoryBuffer API to use ErrorOr.Rafael Espindola1-3/+4
llvm-svn: 212405
2014-06-24Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.Rafael Espindola1-3/+3
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-4/+5
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-06-13Remove 'using std::errro_code' from lib.Rafael Espindola1-7/+6
llvm-svn: 210871
2014-06-12Don't use 'using std::error_code' in include/llvm.Rafael Espindola1-0/+1
This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12Remove system_error.h.Rafael Espindola1-1/+1
This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-2/+1
This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-05[C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles1-1/+1
llvm-svn: 202957
2014-02-21Shankar kindly pointed out that I wasn't following the coding convention ↵Aaron Ballman1-1/+1
properly, so moving raw_ostream.h above system_error.h. llvm-svn: 201885
2014-02-21Fixing the MSVC build by including a file.Aaron Ballman1-0/+1
llvm-svn: 201884
2014-02-21Add a SymbolicFile interface between Binary and ObjectFile.Rafael Espindola1-1/+10
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
2014-01-24Make ObjectFile ownership of the MemoryBuffer optional.Rafael Espindola1-7/+9
This allows llvm-ar to mmap the input files only once. llvm-svn: 200040
2014-01-22Pass the computed magic to createBinary and createObjectFile if available.Rafael Espindola1-2/+4
identify_magic is not free, so we should avoid calling it twice. The argument also makes it cheap for createBinary to just forward to createObjectFile. llvm-svn: 199813
2014-01-22Change createObjectFile to return an ErrorOr.Rafael Espindola1-14/+10
llvm-svn: 199776
2014-01-21Be a bit more consistent about using ErrorOr when constructing Binary objects.Rafael Espindola1-3/+3
The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. llvm-svn: 199770
2013-11-15Path: Recognize COFF import library file magic.Rui Ueyama1-0/+1
Summary: Make identify_magic to recognize COFF import file. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2165 llvm-svn: 194852
2013-10-15Path: Recognize Windows compiled resource file.Rui Ueyama1-0/+1
Some background: One can pass compiled resource files (.res files) directly to the linker on Windows. If a resource file is given, the linker will run "cvtres" command in background to convert the resource file to a COFF file to link it. What I'm trying to do with this patch is to make the linker to recognize the resource file by file magic, so that it can run cvtres command. Differential Revision: http://llvm-reviews.chandlerc.com/D1943 llvm-svn: 192742
2013-07-24Delete the buffer in createObjectFile if it fails.Rafael Espindola1-1/+4
The Binary constructor takes ownership of the memory buffer. This is a fairly unfortunate interface, but for now make createObjectFile consistent with it by also deleting the buffer if it fails. Fixes a leak in llvm-ar found by the valgrind bots. llvm-svn: 187039
2013-06-18Basic support for parsing Mach-O universal binaries in LLVMObject libraryAlexey Samsonov1-0/+1
llvm-svn: 184191
2013-06-11Fix variable name style. Don't cast to and from int.Rafael Espindola1-0/+2
This enables the compiler to see the enum and produce warnings about a switch not being fully covered. Fix one of these warnings. llvm-svn: 183749
2013-06-11Convert another use of sys::identifyFileType.Rafael Espindola1-25/+26
No functionality change. llvm-svn: 183747
2013-06-10Pass a StringRef to sys::identifyFileType.Rafael Espindola1-2/+1
llvm-svn: 183669
2013-05-30Change how we iterate over relocations on ELF.Rafael Espindola1-0/+4
For COFF and MachO, sections semantically have relocations that apply to them. That is not the case on ELF. In relocatable objects (.o), a section with relocations in ELF has offsets to another section where the relocations should be applied. In dynamic objects and executables, relocations don't have an offset, they have a virtual address. The section sh_info may or may not point to another section, but that is not actually used for resolving the relocations. This patch exposes that in the ObjectFile API. It has the following advantages: * Most (all?) clients can handle this more efficiently. They will normally walk all relocations, so doing an effort to iterate in a particular order doesn't save time. * llvm-readobj now prints relocations in the same way the native readelf does. * probably most important, relocations that don't point to any section are now visible. This is the case of relocations in the rela.dyn section. See the updated relocation-executable.test for example. llvm-svn: 182908
2013-04-29Add getSymbolAlignment to the ObjectFile interface.Rafael Espindola1-0/+6
For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-07Remove unused argument.Rafael Espindola1-1/+1
llvm-svn: 178987
2013-01-25When encountering an unknown file format, ObjectFile::createObjectFile shouldEli Bendersky1-1/+3
politely report it instead of running into llvm_unreachable. Also patch llvm-dwarfdump to actually check whether the file it's attempting to dump is a valid object file. llvm-svn: 173489
2011-12-25Remove unused variables.Rafael Espindola1-1/+1
llvm-svn: 147261
generated by cgit v1.1 at 2025-10-05 11:26:55 +0000