summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/BinaryFormat
Commit message (Collapse)AuthorAgeFilesLines
* [BinaryFormat] Teach identify_magic about Tapi files.Cyndy Ishida2019-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "raw_ostream: add operator<< overload for std::error_code"Pavel Labath2019-08-141-1/+10
| | | | | | | | | | | This reverts commit r368849, because it breaks some bots (e.g. llvm-clang-x86_64-win-fast). It turns out this is not as NFC as we had hoped, because operator== will consider two std::error_codes to be distinct even though they both hold "success" values if they have different categories. llvm-svn: 368854
* raw_ostream: add operator<< overload for std::error_codePavel Labath2019-08-141-10/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: The main motivation for this is unit tests, which contain a large macro for pretty-printing std::error_code, and this macro is duplicated in every file that needs to do this. However, the functionality may be useful elsewhere too. In this patch I have reimplemented the existing ASSERT_NO_ERROR macros to reuse the new functionality, but I have kept the macro (as a one-liner) as it is slightly more readable than ASSERT_EQ(..., std::error_code()). Reviewers: sammccall, ilya-biryukov Subscribers: zturner, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65643 llvm-svn: 368849
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [YAMLIO] Remove trailing spaces when outputting mapsFangrui Song2019-07-121-2/+2
| | | | | | | | | | | | | | | | | | llvm::yaml::Output::paddedKey unconditionally outputs spaces, which are superfluous if the value to be dumped is a sequence or map. Change `bool NeedsNewLine` to `StringRef Padding` so that it can be overridden to `\n` if the value is a sequence or map. An empty map/sequence is special. It is printed as `{}` or `[]` without a newline, while a non-empty map/sequence follows a newline. To handle this distinction, add another variable `PaddingBeforeContainer` and does the special handling in endMapping/endSequence. Reviewed By: grimar, jhenderson Differential Revision: https://reviews.llvm.org/D64566 llvm-svn: 365869
* [MsgPack] Removed MsgPackTypesTim Renouf2019-03-132-188/+0
| | | | | | | | | | Summary: MsgPackTypes has been replaced by the lighter-weight MsgPackDocument. Differential Revision: https://reviews.llvm.org/D57025 Change-Id: Ia7069880ef29f55490abbe5d8ae15f25cc1490a4 llvm-svn: 356082
* [MsgPack] New MsgPackDocument classTim Renouf2019-03-132-0/+169
| | | | | | | | | | | | | | | | | | | Summary: A class that exposes a simple in-memory representation of a document of MsgPack objects, that can be read from and written to MsgPack, read from and written to YAML, and inspected and modified in memory. This is intended to be a lighter-weight (in terms of memory allocations) replacement for MsgPackTypes. Two subsequent changes will: 1. switch AMDGPU HSA metadata to using MsgPackDocument instead of MsgPackTypes; 2. add MsgPack AMDGPU PAL metadata via MsgPackDocument. Differential Revision: https://reviews.llvm.org/D57023 Change-Id: Ie15a054831d5a6467c5867c064c8f8f6b80270e1 llvm-svn: 356080
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-196-24/+18
| | | | | | | | | | | | | | | | | 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
* [BinaryFormat] Add MsgPackTypesScott Linder2018-11-152-0/+189
| | | | | | | | | Add data structure to represent MessagePack "documents" and convert to/from both MessagePack and YAML encodings. Differential Revision: https://reviews.llvm.org/D48175 llvm-svn: 346978
* Fix comparison of char and int64 in TestWriteFixNegativeIntVitaly Buka2018-08-231-1/+1
| | | | | | It was broken on clang-ppc64le-linux-lnt bot. llvm-svn: 340517
* [BinaryFormat] Add MessagePack reader/writerScott Linder2018-08-223-0/+1416
| | | | | | | | | | | | | | Add support for reading and writing MessagePack, a binary object serialization format which aims to be more compact than text formats like JSON or YAML. The specification can be found at https://github.com/msgpack/msgpack/blob/master/spec.md Will be used for encoding metadata in AMDGPU code objects. Differential Revision: https://reviews.llvm.org/D44429 llvm-svn: 340457
* Re-land: [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-032-0/+48
| | | | | | | | | | | | | | This re-lands r333797 with a fix for big endian systems. Original commit message: This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333854
* Revert "Re-land: [MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-012-48/+0
| | | | | | | | This reverts commit r333803. Still breaking on big endian. Will sort this out later. llvm-svn: 333805
* Re-land: [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-012-0/+48
| | | | | | | | | | | | | | This re-lands r333797 with a fix for big endian systems. Original commit message: This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333803
* Revert "[MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-012-44/+0
| | | | | | | | | | This reverts commit r333797. This patch is failing on BigEndian bots. I will fix and re-land: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/19505/ llvm-svn: 333799
* [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-012-0/+44
| | | | | | | | | | This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333797
* [dwarf] Unify unknown dwarf enum formatting codePavel Labath2018-03-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We have had at least three pieces of code (in DWARFAbbreviationDeclaration, DWARFAcceleratorTable and DWARFDie) that have hand-rolled support for dumping unknown dwarf enum values. While not terrible, they are a bit distracting and enable small differences to creep in (Unknown_ffff vs. Unknown_0xffff). I ended up needing to add a fourth place (DWARFVerifier), so it seems it would be a good time to centralize. This patch creates an alternative to the XXXString dumping functions in the BinaryFormat library, which formats an unknown value as DW_TYPE_unknown_1234, instead of just an empty string. It is based on the formatv function, as that allows us to avoid materializing the string for unknown values (and because this way I don't have to invent a name for the new functions :P). In this patch I add formatters for dwarf attributes, forms, tags, and index attributes as these are the ones in use currently, but adding other enums is straight-forward. Reviewers: dblaikie, JDevlieghere, aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44570 llvm-svn: 328090
* DWARF: Unify form size handling codePavel Labath2018-03-141-0/+53
| | | | | | | | | | | | | | | | | Summary: This patch replaces the two switches which are deducing the size of various forms with a single implementation. I have put the new implementation into BinaryFormat, to avoid introducing dependencies between the two independent libraries (DebugInfo and CodeGen) that need this functionality. Reviewers: aprantl, JDevlieghere, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44418 llvm-svn: 327486
* Teach identify_file_magic to identify PDB files.Zachary Turner2018-03-071-0/+3
| | | | llvm-svn: 326924
* [BinaryFormat] Fix out of bounds read.Benjamin Kramer2017-08-311-1/+4
| | | | | | | Found by OSS-FUZZ! https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3220 llvm-svn: 312238
* Revert "Revert "Revert "Revert "Switch external cvtres.exe for llvm's own ↵Eric Beckmann2017-07-081-1/+2
| | | | | | | | | | | | | | | | | | | | resource library."""" This reverts commit 147f45ff24456aea59575fa4ac16c8fa554df46a. Revert "Revert "Revert "Revert "Replace trivial use of external rc.exe by writing our own .res file."""" This reverts commit 61a90a67ed54a1f0dfeab457b65abffa129569e4. The patches were intially reverted because they were causing a failure on CrWinClangLLD. Unfortunately, this was done haphazardly and didn't compile, so the revert was reverted again quickly to fix this. One that was done, the revert of the revert was itself reverted. This allowed me to finally fix the actual bug in r307452. This patch re-enables the code path that had originally been causing the bug, now that it (should) be fixed. llvm-svn: 307460
* Revert "Revert "Revert "Replace trivial use of external rc.exe by writing ↵Eric Beckmann2017-07-051-2/+1
| | | | | | | | | | | | | | our own .res file.""" This reverts commit 5fecbbbe5049665d86834cf69d8f75db4f392308. The initial revert was done in order to prevent ongoing errors on chromium bots such as CrWinClangLLD. However, this was done haphazardly and I didn't realize there were test and compilation failures, so this revert was reverted. Now that those have been fixed, we can revert the revert of the revert. llvm-svn: 307226
* Revert "Revert "Replace trivial use of external rc.exe by writing our own ↵Eric Beckmann2017-07-051-1/+2
| | | | | | | | .res file."" This reverts commit 8c8dce3b8f15d6ebaefc35ce88f15a85c8cdbd6e. llvm-svn: 307191
* Revert "Replace trivial use of external rc.exe by writing our own .res file."Eric Beckmann2017-07-051-2/+1
| | | | | | | | | This patch still seems to break CrWinClangLLD, reverting this once more until I can discover root problem. This reverts commit 3dbbc8ce43be50ffde2b1c655c6d3a25796fe78b. llvm-svn: 307188
* Revert "Revert "Replace trivial use of external rc.exe by writing our own ↵Eric Beckmann2017-07-011-1/+2
| | | | | | | | | | | | | | | | | | .res file."" Summary: This reverts commit 51931072a7c9a52540baf76fc30ef391d2529a2f. This revert was originally done because the integrations of the new WindowsResource library into LLD was causing error in chromium, due to bugs in how resource sections were handled. These bugs were fixed, meaning that the features may be reintegrated. Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D34922 llvm-svn: 306941
* Revert "Replace trivial use of external rc.exe by writing our own .res file."Eric Beckmann2017-06-291-2/+1
| | | | | | | | | | | | | | | This reverts commit d4c7e9fc63c10dbab0c30186ef8575474a704496. This is done in order to address the failure of CrWinClangLLD etc. bots. These throw an error of "side-by-side configuration is incorrect" during compilation, which sounds suspiciously related to these manifest changes. Revert "Switch external cvtres.exe for llvm's own resource library." This reverts commit 71fe8ef283a9dab9a3f21432c98466cbc23990d1. llvm-svn: 306618
* Replace trivial use of external rc.exe by writing our own .res file.Eric Beckmann2017-06-261-1/+2
| | | | | | | | | This patch removes the dependency on the external rc.exe tool by writing a simple .res file using our own library. In this patch I also added an explicit definition for the .res file magic. Furthermore, I added a unittest for embeded manifests and fixed a bug exposed by the test. llvm-svn: 306311
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-073-0/+279
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
OpenPOWER on IntegriCloud