aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/ObjectFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-05-26[NFC][object] Change the input parameter of the method isDebugSection.Esme-Yi1-3/+1
Summary: This is a NFC patch to change the input parameter of the method SectionRef::isDebugSection(), by replacing the StringRef SectionName with DataRefImpl Sec. This allows us to determine if a section is debug type in more ways than just by section name. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D102601
2020-11-09Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some ↵Georgii Rymar1-2/+3
elements are corrupt. This is recommit for D90903 with fixes for BB: 1) Used std::move<> when returning Expected<> (http://lab.llvm.org:8011/#/builders/112/builds/913) 2) Fixed the name of temporarily file in the file-headers.test (http://lab.llvm.org:8011/#/builders/36/builds/1269) (a local old temporarily file was used before) For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-11-09Revert "[llvm-readelf/obj] - Allow dumping of ELF header even if some ↵Georgii Rymar1-3/+2
elements are corrupt." This reverts commit ea8a0b8b29eb08d3f0f6ac40942a2d8e98ab57ee. It broke BBots. http://lab.llvm.org:8011/#/builders/14/builds/1439 http://lab.llvm.org:8011/#/builders/112/builds/913
2020-11-09[llvm-readelf/obj] - Allow dumping of ELF header even if some elements are ↵Georgii Rymar1-2/+3
corrupt. For creating `ELFObjectFile` instances we have the factory method `ELFObjectFile<ELFT>::create(MemoryBufferRef Object)`. The problem of this method is that it scans the section header to locate some sections. When a file is truncated or has broken fields in the ELF header, this approach does not allow us to create the `ELFObjectFile` and dump the ELF header. This is https://bugs.llvm.org/show_bug.cgi?id=40804 This patch suggests a solution - it allows to delay scaning sections in the `ELFObjectFile<ELFT>::create`. It now allows user code to call an object initialization (`initContent()`) later. With that it is possible, for example, for dumpers just to dump the file header and exit. By default initialization is still performed as before, what helps to keep the logic of existent callers untouched. I've experimented with different approaches when worked on this patch. I think this approach is better than doing initialization of sections (i.e. scan of them) on demand, because normally users of `ELFObjectFile` API expect to work with a valid object. In most cases when a section header table can't be read (because of an error), we don't have to continue to work with object. So we probably don't need to implement a more complex API. Differential revision: https://reviews.llvm.org/D90903
2020-05-02[Object] Change ObjectFile::getSymbolValue() return type to Expected<uint64_t>Xing GUO1-3/+3
Summary: In D77860, we have changed `getSymbolFlags()` return type to `Expected<uint32_t>`. This change helps bubble the error further up the stack. Reviewers: jhenderson, grimar, JDevlieghere, MaskRay Reviewed By: jhenderson Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79075
2020-04-18[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> ↵vgxbj1-5/+8
getSymbolFlags(). This change enables getSymbolFlags() to return errors which benefit error reporting in clients. Differential Revision: https://reviews.llvm.org/D77860
2020-04-02[Object] Add the method for checking if a section is a debug sectionDjordje Todorovic1-0/+4
Different file formats have different naming style for the debug sections. The method is implemented for ELF, COFF and Mach-O formats. Differential Revision: https://reviews.llvm.org/D76276
2020-03-31[Object] Update ObjectFile::makeTriple for XCOFFHubert Tong1-4/+7
Summary: When we encounter an XCOFF file, reflect that in the triple information. In addition to knowing the object file format, we know that the associated OS is AIX. This means that we can expect that there is no output difference in the processing of an XCOFF32 input file between cases where the triple is left unspecified by the user and cases where the user specifies `--triple powerpc-ibm-aix` explicitly. Reviewers: jhenderson, sfertile, jasonliu, daltenty Reviewed By: jasonliu Subscribers: wuzish, nemanjai, hiraditya, MaskRay, rupprecht, steven.zhang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77025
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling1-1/+1
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling1-1/+1
2019-11-19Add operator<< for object::SectionedAddressPavel Labath1-0/+7
The main motivation for this is better failure messages in unit tests. Split off from D70394.
2019-10-21[llvm/Object] - Make ELFObjectFile::getRelocatedSection return ↵George Rimar1-1/+2
Expected<section_iterator> It returns just a section_iterator currently and have a report_fatal_error call inside. This change adds a way to return errors and handle them on caller sides. The patch also changes/improves current users and adds test cases. Differential revision: https://reviews.llvm.org/D69167 llvm-svn: 375408
2019-10-01ObjectFile makeTriple - silence static analyzer dyn_cast<COFFObjectFile> ↵Simon Pilgrim1-1/+1
null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<COFFObjectFile> directly and if not assert will fire for us. llvm-svn: 373324
2019-09-02Recommit r370661 "[llvm-nm] - Add a test case for case when we dump a symbol ↵George Rimar1-1/+3
that belongs to a section with a broken sh_name." Fix: add a 'consumeError()' call to ObjectFile.cpp. This error was never checked. Original commit message: It adds a test case for a problem fixed by D66976 <https://reviews.llvm.org/D66976>. It was introduced by me in D66089 <https://reviews.llvm.org/D66089>. The error reported was never consumed because of a wrong variable name used, so it could fail when LLVM_ENABLE_ABI_BREAKING_CHECKS is used. Differential revision: https://reviews.llvm.org/D67002 llvm-svn: 370669
2019-08-21[BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida1-0/+2
Summary: Tapi files are YAML files that start with the !tapi tag. The only execption are TBD v1 files, which don't have a tag. In that case we have to scan a little further and check if the first key "archs" exists. This is the first patch in a series of patches to add libObject support for text-based dynamic library (.tbd) files. This patch is practically exactly the same as D37820, that was never pushed to master, and is needed for future commits related to reading tbd files for llvm-nm Reviewers: ributzka, steven_wu, bollu, espindola, jfb, shafik, jdoerfert Reviewed By: steven_wu Subscribers: dexonsmith, llvm-commits Tags: #llvm, #clang, #sanitizers, #lldb, #libc, #openmp Differential Revision: https://reviews.llvm.org/D66149 llvm-svn: 369579
2019-07-09[Object][XCOFF] Add support for 64-bit file header and section header dumping.Sean Fertile1-1/+3
Adds a readobj dumper for 32-bit and 64-bit section header tables, and extend support for the file-header dumping to include 64-bit object files. Also refactors the binary file parsing to be done in a helper function in an attempt to cleanup error handeling. Differential Revision: https://reviews.llvm.org/D63843 llvm-svn: 365524
2019-05-10[Object] Change SymbolicFile::printSymbolName to use ErrorFangrui Song1-4/+3
llvm-svn: 360414
2019-05-02[Object] Change getSectionName() to return Expected<StringRef>Fangrui Song1-3/+2
Summary: It currently receives an output parameter and returns std::error_code. Expected<StringRef> fits for this purpose perfectly. Differential Revision: https://reviews.llvm.org/D61421 llvm-svn: 359774
2019-04-04[XCOFF] Add functionality for parsing AIX XCOFF object file headersHubert Tong1-0/+2
Summary: 1. Add functionality for parsing AIX XCOFF object files headers. 2. Only support 32-bit AIX XCOFF object files in this patch. 3. Print out the AIX XCOFF object file header in YAML format. Reviewers: sfertile, hubert.reinterpretcast, jasonliu, mstorsjo, zturner, rnk Reviewed By: sfertile, hubert.reinterpretcast Subscribers: jsji, mgorny, hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59419 Patch by Digger Lin llvm-svn: 357663
2019-03-21[Object] Add basic minidump supportPavel Labath1-0/+1
Summary: This patch adds basic support for reading minidump files. It contains the definitions of various important minidump data structures (header, stream directory), and of one minidump stream (SystemInfo). The ability to read other streams will be added in follow-up patches. However, all streams can be read even now as raw data, which means lldb's minidump support (where this code is taken from) can be immediately rebased on top of this patch as soon as it lands. As we don't have any support for generating minidump files (yet), this tests the code via unit tests with some small handcrafted binaries in the form of c char arrays. Reviewers: Bigcheese, jhenderson, zturner Subscribers: srhines, dschuff, mgorny, fedor.sergeev, lemo, clayborg, JDevlieghere, aprantl, lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59291 llvm-svn: 356652
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-12-13[llvm-size][libobject] Add explicit "inTextSegment" methods similar to ↵Jordan Rupprecht1-0/+8
"isText" section methods to calculate size correctly. Summary: llvm-size uses "isText()" etc. which seem to indicate whether the section contains code-like things, not whether or not it will actually go in the text segment when in a fully linked executable. The unit test added (elf-sizes.test) shows some types of sections that cause discrepencies versus the GNU size tool. llvm-size is not correctly reporting sizes of things mapping to text/data segments, at least for ELF files. This fixes pr38723. Reviewers: echristo, Bigcheese, MaskRay Reviewed By: MaskRay Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54369 llvm-svn: 349074
2018-03-07Update a few switch statements to handle file_magic::pdb.Zachary Turner1-0/+1
This fixes a couple of warnings. llvm-svn: 326927
2017-10-10Convert two uses of ErrorOr to Expected.Rafael Espindola1-2/+2
llvm-svn: 315354
2017-09-26[dwarfdump] Skip 'stripped' sectionsJonas Devlieghere1-0/+2
When dsymutil generates the companion file, its strips all unnecessary sections by omitting their body and setting the offset in their corresponding load command to zero. One such section is the .eh_frame section, as it contains runtime information rather than debug information and is part of the __TEXT segment. When reading this section, we would just read the number of bytes specified in the load command, starting from offset 0 (i.e. the beginning of the file). Rather than trying to parse this obviously invalid section, dwarfdump now skips this. Differential revision: https://reviews.llvm.org/D38135 llvm-svn: 314208
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
generated by cgit v1.1 at 2025-10-03 16:03:04 +0000