aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/Binary.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-06-01[Binary] Promote OffloadBinary to inherit from BinaryJoseph Huber1-0/+3
We use the `OffloadBinary` to create binary images of offloading files and their corresonding metadata. This patch changes this to inherit from the base `Binary` class. This allows us to create and insepect these more generically. This patch includes all the necessary glue to implement this as a new binary format, along with added the magic bytes we use to distinguish the offloading binary to the `file_magic` implementation. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D126812
2022-05-02[NFC] Add missing switch casesChris Bieneman1-0/+1
This silences warnings encountered on some bots.
2022-03-14[CUDA] Add CUDA fatbinary magicJoseph Huber1-0/+1
Nvidia uses fatbinaries to bundle all of their device code. This patch adds the magic number "0x50ed55ba" used in their propeitary format to the list of magic identifies. This is technically undocumented and could unlikely be changed by Nvidia in the future. Reviewed By: tra Differential Revision: https://reviews.llvm.org/D120932
2022-02-10Cleanup LLVMObject headersserge-sans-paille1-2/+0
Most notably, llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h llvm/Object/TapiUniversal.h no longer includes llvm/Object/TapiFile.h llvm-project preprocessed size: before: 1068185081 after: 1068324320 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D119457
2021-07-20[SystemZ][z/OS] Add GOFF support to file magic identificationAnirudh Prasad1-0/+1
- This patch adds in the GOFF format to the file magic identification logic in LLVM - Currently, for the object file support, GOFF is marked as having as an error - However, this is only temporary until https://reviews.llvm.org/D98437 is merged in Reviewed By: abhina.sreeskantharajan Differential Revision: https://reviews.llvm.org/D105993
2021-03-25[NFC] Reordering parameters in getFile and getFileOrSTDINAbhina Sreeskantharajan1-1/+1
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used. ``` static ErrorOr<std::unique_ptr<MemoryBuffer>> getFile(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true, bool IsVolatile = false); static ErrorOr<std::unique_ptr<MemoryBuffer>> getFileOrSTDIN(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true); static ErrorOr<std::unique_ptr<MB>> getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset, bool IsText, bool RequiresNullTerminator, bool IsVolatile); static ErrorOr<std::unique_ptr<WritableMemoryBuffer>> getFile(const Twine &Filename, bool IsVolatile = false); ``` Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D99182
2020-11-09Recommit: [llvm-readelf/obj] - Allow dumping of ELF header even if some ↵Georgii Rymar1-5/+6
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-6/+5
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-5/+6
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-08-25[llvm-lipo] Add support for bitcode filesAdrien Guinet1-2/+3
A Mach-O universal binary may contain bitcode as a slice. This diff adds proper handling of such binaries to llvm-lipo. Test plan: make check-all Differential revision: https://reviews.llvm.org/D85740
2019-08-21[Object] Add tapi files to objectCyndy Ishida1-2/+2
Summary: The intention for this is to allow reading and printing symbols out from llvm-nm. Tapi file, and Tapi universal follow a similiar format to their respective MachO Object format. The tests are dependent on llvm-nm processing tbd files which is why its in D66160 Reviewers: ributzka, steven_wu, lhames Reviewed By: ributzka, lhames Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66159 llvm-svn: 369600
2019-08-21[BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida1-0/+3
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-0/+1
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-04-04[XCOFF] Add functionality for parsing AIX XCOFF object file headersHubert Tong1-0/+1
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/+3
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
2019-01-09Don't require a null terminator when loading objectsDavid Major1-1/+2
When a null terminator is required and the file size is a multiple of the system page size, MemoryBuffer will prefer pread() over mmap(), which can result in excessive memory usage. Patch by Mike Hommey! Differential Revision: https://reviews.llvm.org/D56475 llvm-svn: 350774
2018-03-07Update a few switch statements to handle file_magic::pdb.Zachary Turner1-0/+3
This fixes a couple of warnings. llvm-svn: 326927
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-33/+34
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-05-20Add functionality to cvtres to parse all entries in res file.Eric Beckmann1-1/+3
Summary: Added the new modules in the Object/ folder. Updated the llvm-cvtres interface as well, and added additional tests. Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33180 llvm-svn: 303480
2017-04-19[Object] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko1-8/+12
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-06-29Change Archive::create() from ErrorOr<...> to Expected<...> and updateKevin Enderby1-1/+1
its clients. This commit will break the next lld builds. I’ll be committing the matching change for lld next. llvm-svn: 274160
2016-06-27Change all but the last ErrorOr<...> use for MachOUniversalBinary to ↵Kevin Enderby1-1/+1
Expected<...> to allow a good error message to be produced. I added the one test case that the object file tools could produce an error message. The other two errors can’t be triggered if the input file is passed through sys::fs::identify_magic(). But the malformedError("bad magic number") does get triggered by the logic in llvm-dsymutil when dealing with a normal Mach-O file. The other "File too small ..." error would take a logic error currently to produce and is not tested for. llvm-svn: 273946
2016-04-06Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump ↵Kevin Enderby1-9/+9
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-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-09-03unique_ptrify MachOUniversalBinary::createDavid Blaikie1-2/+1
llvm-svn: 217052
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-16/+21
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-3/+4
llvm-svn: 214377
2014-07-21Correct the ownership passing semantics of object::createBinary and make ↵David Blaikie1-2/+2
them explicit in the type system. createBinary documented that it destroyed the parameter in error cases, though by observation it does not. By passing the unique_ptr by value rather than lvalue reference, callers are now explicit about passing ownership and the function implements the documented contract. Remove the explicit documentation, since now the behavior cannot be anything other than what was documented, so it's redundant. Also drops a unique_ptr::release in llvm-nm that was always run on a null unique_ptr anyway. llvm-svn: 213557
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-4/+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-4/+4
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-13/+8
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-12Don't use 'using std::error_code' in include/llvm.Rafael Espindola1-1/+1
This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-2/+2
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-4/+4
llvm-svn: 202957
2014-02-21Add a SymbolicFile interface between Binary and ObjectFile.Rafael Espindola1-5/+5
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-29Make createObjectFile's signature a bit less error prone.Rafael Espindola1-1/+1
This will be better with c++11, but right now file_magic converts to bool, which makes the api really easy to misuse. llvm-svn: 200357
2014-01-24Make ObjectFile ownership of the MemoryBuffer optional.Rafael Espindola1-4/+4
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-10/+10
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-21Be a bit more consistent about using ErrorOr when constructing Binary objects.Rafael Espindola1-35/+10
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
2014-01-15Return an ErrorOr<Binary *> from createBinary.Rafael Espindola1-31/+25
I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too cumbersome to use without std::move. I will keep the patch locally and submit when we switch to c++11. llvm-svn: 199326
2014-01-07Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth1-1/+1
subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
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-1/+2
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
generated by cgit v1.1 at 2025-10-03 20:37:00 +0000