summaryrefslogtreecommitdiffstats
path: root/llvm/test/tools/llvm-objcopy/Inputs
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-objcopy] [COFF] Fix handling of aux symbols for big objectsMartin Storsjo2019-01-231-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The aux symbols were stored in an opaque std::vector<uint8_t>, with contents interpreted according to the rest of the symbol. All aux symbol types but one fit in 18 bytes (sizeof(coff_symbol16)), and if written to a bigobj, two extra padding bytes are written (as sizeof(coff_symbol32) is 20). In the storage agnostic intermediate representation, store the aux symbols as a series of coff_symbol16 sized opaque blobs. (In practice, all such aux symbols only consist of one aux symbol, so this is more flexible than what reality needs.) The special case is the file aux symbols, which are written in potentially more than one aux symbol slot, without any padding, as one single long string. This can't be stored in the same opaque vector of fixed sized aux symbol entries. The file aux symbols will occupy a different number of aux symbol slots depending on the type of output object file. As nothing in the intermediate process needs to have accurate raw symbol indices, updating that is moved into the writer class. Differential Revision: https://reviews.llvm.org/D57009 llvm-svn: 351947
* [llvm-objcopy] Move elf-specific tests into subfolderAlexander Shaposhnikov2018-11-3010-34/+0
| | | | | | | | | | | | | | In this diff the elf-specific tests are moved into the subfolder llvm-objcopy/ELF (the change was discussed in the comments on https://reviews.llvm.org/D54674). A separate code reivew wasn't sent for this change since Phabricator is failing to create such a large diff. Test plan: make check-all make check-llvm-tools make check-llvm-tools-llvm-objcopy llvm-svn: 347958
* [llvm-objcopy] Dwarf .debug section compression support (zlib, zlib-gnu).Puyan Lotfi2018-09-071-0/+21
| | | | | | | | | | | | | | | | | | | | | | | Third Attempt: - Alignment issues resolved. - zlib::isAvailable() detected. - ArrayRef misuse fixed. Usage: llvm-objcopy --compress-debug-sections=zlib foo.o llvm-objcopy --compress-debug-sections=zlib-gnu foo.o In both cases the debug section contents is compressed with zlib. In the GNU style case the header is the "ZLIB" magic string followed by the uint64 big- endian decompressed size. In the non-GNU mode the header is the Elf(32|64)_Chdr. Decompression support is coming soon. Differential Revision: https://reviews.llvm.org/D49678 llvm-svn: 341635
* Revert: [llvm-objcopy] Dwarf .debug section compression (Second Attempt).Puyan Lotfi2018-09-071-21/+0
| | | | | | Various bots still fail for unknown reason. llvm-svn: 341613
* [llvm-objcopy] Dwarf .debug section compression support (zlib, zlib-gnu).Puyan Lotfi2018-09-061-0/+21
| | | | | | | | | | | | | | | | | | | | Second Attempt. Alignment issues resolved. zlib::isAvailable() detected. Usage: llvm-objcopy --compress-debug-sections=zlib foo.o llvm-objcopy --compress-debug-sections=zlib-gnu foo.o In both cases the debug section contents is compressed with zlib. In the GNU style case the header is the "ZLIB" magic string followed by the uint64 big- endian decompressed size. In the non-GNU mode the header is the Elf(32|64)_Chdr. Decompression support is coming soon. Differential Revision: https://reviews.llvm.org/D49678 llvm-svn: 341607
* Revert r341342: Dwarf .debug section compression support (zlib, zlib-gnu).Chandler Carruth2018-09-041-21/+0
| | | | | | | | | | | | Also reverts follow-up commits r341343 and r341344. The primary commit continues to break some build bots even after the fixes in r341343 for UBSan issues: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/5823 It is also failing for me locally (linux, x86-64). llvm-svn: 341360
* [llvm-objcopy] Dwarf .debug section compression support (zlib, zlib-gnu).Puyan Lotfi2018-09-031-0/+21
| | | | | | | | | | | | | | | | | | | Usage: llvm-objcopy --compress-debug-sections=zlib foo.o llvm-objcopy --compress-debug-sections=zlib-gnu foo.o In both cases the debug section contents is compressed with zlib. In the GNU style case the header is the "ZLIB" magic string followed by the uint64 big- endian decompressed size. In the non-GNU mode the header is the Elf(32|64)_Chdr. Decompression support is coming soon. Differential Revision: https://reviews.llvm.org/D49678 llvm-svn: 341342
* [llvm-objcopy, tests] Fix several llvm-objcopy testsStella Stamenova2018-07-201-1/+9
| | | | | | | | | | | | | | Summary: In Python 3, sys.stdout.write expects a string rather than bytes. In order to be able to write the bytes to stdout, we need to use the buffer directly instead. This change is borrowing the implementation for writing to stdout that cat.py uses. Note that we cannot use cat.py directly because the file we are trying to open is a gzip file. Reviewers: asmith, bkramer, alexshap, jakehehrlich Reviewed By: alexshap, jakehehrlich Subscribers: jakehehrlich, llvm-commits Differential Revision: https://reviews.llvm.org/D49515 llvm-svn: 337567
* [llvm-objcopy] Add support for large indexesJake Ehrlich2018-07-162-0/+5
| | | | | | | | | | | | | | | | | | | This patch is an update of an older patch that never landed (see here: https://reviews.llvm.org/D42516) Recently various users have run into this issue and it just 100% has to be solved at this point. The main difference in this patch is that I use gunzip instead of unzip which should hopefully allow tests to pass. Please review this as if it is a new patch however. I found some issues along the way and made some minor modifications. The binary used in this patch for testing (a zip file to make it small) can be found here: https://drive.google.com/file/d/1UjsnTO9edLttZibbr-2T1bJl92KEQFAO/view?usp=sharing Differential Revision: https://reviews.llvm.org/D49206 llvm-svn: 337204
* [llvm-objcopy] Implement support for section groupsAlexander Shaposhnikov2018-03-211-0/+0
| | | | | | | | | | | | | | | | | | | This diff adds support for SHT_GROUP sections to llvm-objcopy. Some sections are interrelated and comprise a group. For example, a definition of an inline function might require, in addition to the section containing its instructions, a read-only data section containing literals referenced inside the function. A section of the type SHT_GROUP contains the indices of the group members, therefore, it needs to be updated whenever the indices change. Similarly, the fields sh_link, sh_info should be recalculated as well. [Resubmit r328012 with the proper handling of endianness] Test plan: make check-all Differential revision: https://reviews.llvm.org/D43996 llvm-svn: 328143
* [llvm-objcopy] Revert the tests from r328012Alexander Shaposhnikov2018-03-201-0/+0
| | | | | | Temporarily revert the tests from r328012 as well. llvm-svn: 328026
* [llvm-objcopy] Implement support for section groupsAlexander Shaposhnikov2018-03-201-0/+0
| | | | | | | | | | | | | | | | | This diff adds support for SHT_GROUP sections to llvm-objcopy. Some sections are interrelated and comprise a group. For example, a definition of an inline function might require, in addition to the section containing its instructions, a read-only data section containing literals referenced inside the function. A section of the type SHT_GROUP contains the indices of the group members, therefore, it needs to be updated whenever the indices change. Similarly, the fields sh_link, sh_info should be recalculated as well. Test plan: make check-all Differential revision: https://reviews.llvm.org/D43996 llvm-svn: 328012
* Revert "[llvm-objcopy] Add support for large indexes"Jake Ehrlich2018-03-071-0/+0
| | | | | | | | Not all build bots have unzip which I used in a test. This reverts commit 0b1f26d39ea42dd3716b525fbc8c78d8c7bb4479. llvm-svn: 326941
* [llvm-objcopy] Add support for large indexesJake Ehrlich2018-03-071-0/+0
| | | | | | | | | | | | | Because of -ffunction-sections (and maybe other use cases I'm not aware of?) it can occur that we need more than 0xfeff sections but ELF dosn't support that many sections. To solve this problem SHN_XINDEX exists and with it come a whole host of changes for section indexes everywhere. This change adds support for those cases which should allow llvm-objcopy to copy binaries that have an arbitrary number of sections. Differential Revision: https://reviews.llvm.org/D42516 llvm-svn: 326940
* [llvm-objcopy] Refactor llvm-objcopy to use reader and writer objectsJake Ehrlich2018-01-251-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While writing code for input and output formats in llvm-objcopy it became apparent that there was a code health problem. This change attempts to solve that problem by refactoring the code to use Reader and Writer objects that can read in different objects in different formats, convert them to a single shared internal representation, and then write them to any other representation. New classes: Reader: the base class used to construct instances of the internal representation Writer: the base class used to write out instances of the internal representation ELFBuilder: a helper class for ELFWriter that takes an ELFFile and converts it to a Object SectionVisitor: it became necessary to remove writeSection from SectionBase because, under the new Reader/Writer scheme, it's possible to convert between ELF Types such as ELF32LE and ELF32BE. This isn't possible with writeSection because it (dynamically) depends on the underlying section type *and* (statically) depends on the ELF type. Bad things would happen if the underlying sections for ELF32LE were used for writing to ELF64BE. To avoid this code smell (which would have compiled, run, and output some nonsesnse) I decoupled writing of sections from a class. SectionWriter: This is just the ELFT templated implementation of SectionVisitor. Many classes now have this class as a friend so that the writing methods in this class can write out private data. ELFWriter: This is the Writer that outputs to ELF BinaryWriter: This is the Writer that outputs to Binary ElfType: Because the ELF Type is not a part of the Object anymore we need a way to construct the correct default Writer based on properties of the Reader. This enum just keeps track of the ELF type of the input so it can be used as the default output type as well. Object has correspondingly undergone some serious changes as well. It now has more generic methods for building and manipulating ELF binaries. This interface makes ELFBuilder easy enough to use and will make the BinaryReader/Builder easy to create as well. Most changes in this diff are cosmetic and deal with the fact that a method has been moved from one class to another or a change from a pointer to a reference. Almost no changes should result in a functional difference (this is after all a refactor). One minor functional change was made and the result can be seen in remove-shstrtab-error.test. The fact that it fails hasn't changed but the error message has changed because that failure is detected at a later point in the code now (because WriteSectionHeaders is a property of the ElfWriter *not* a property of the Object). I'd say roughly 80-90% of this code is cosmetically different, 10-19% is different but functionally the same, and 1-5% is functionally different despite not causing a change in tests. Differential Revision: https://reviews.llvm.org/D42222 llvm-svn: 323480
* Reverting r323463 as it appears to be an accidental commit. Regardless, it ↵Aaron Ballman2018-01-251-0/+0
| | | | | | | | | | broke a lot of build bots, so reverting back to green. http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8/builds/9294 http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/24084 http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/9567 llvm-svn: 323465
* tmpJake Ehrlich2018-01-251-0/+0
| | | | llvm-svn: 323463
* [llvm-objcopy] Add support for dwarf fissionJake Ehrlich2017-11-031-0/+0
| | | | | | | | This change adds support for dwarf fission. Differential Revision: https://reviews.llvm.org/D39207 llvm-svn: 317350
* [llvm-objcopy] Add support for dynamic relocationsJake Ehrlich2017-09-261-0/+0
| | | | | | | | | | | | | | | This change adds support for dynamic relocations (allocated SHT_REL/SHT_RELA sections with a dynamic symbol table as their link). The binary I added for the test is here: https://drive.google.com/file/d/0B3gtIAmiMwZXSjJUZE9pUjd4M0k/view?usp=sharing Unless support for dynamic symbol tables in yaml2obj is added this is needed. Differential Revision: https://reviews.llvm.org/D37915 llvm-svn: 314227
* Reland "[llvm-objcopy] Add support for .dynamic, .dynsym, and .dynstr"Jake Ehrlich2017-09-202-0/+0
| | | | | | | | | | | | | I did not upload two binaries that I reference in tests. This change adds support for sections involved in dynamic loading such as SHT_DYNAMIC, SHT_DYNSYM, and allocated string tables. The two added binaries used for tests can be downloaded here and here Differential Revision: https://reviews.llvm.org/D36560 llvm-svn: 313772
* Revert "[llvm-objcopy] Add support for .dynamic, .dynsym, and .dynstr"Jake Ehrlich2017-09-192-0/+0
| | | | | | | This reverts commit r313663. Broken because overlapping-sections was reverted. llvm-svn: 313665
* [llvm-objcopy] Add support for .dynamic, .dynsym, and .dynstrJake Ehrlich2017-09-192-0/+0
| | | | | | | | | | | | | | | This change adds support for sections involved in dynamic loading such as SHT_DYNAMIC, SHT_DYNSYM, and allocated string tables. The two added binaries used for tests can be downloaded [[ https://drive.google.com/file/d/0B3gtIAmiMwZXOXE3T0RobFg4ZTg/view?usp=sharing | here ]] and [[ https://drive.google.com/file/d/0B3gtIAmiMwZXTFJSQUJZMGxNSXc/view?usp=sharing | here ]] Differential Revision: https://reviews.llvm.org/D36560 llvm-svn: 313663
* [llvm][llvm-objcopy] When outputting to binary don't output segments that ↵Petr Hosek2017-08-041-0/+0
cover no sections Sometimes LLD will produce a PT_LOAD segment that only covers the headers (and covers no sections). GNU objcopy does not output the segment contents for these sections. In particular this is an issue in building magenta because the final link step for the kernel would produce just such a PT_LOAD segment. This change is to support this case and to match what GNU objcopy does in this case. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D36196 llvm-svn: 310149
OpenPOWER on IntegriCloud