summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/DebugInfo
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-sort #include lines for unittests. This uses a slightly modifiedChandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | clang-format (https://reviews.llvm.org/D33932) to keep primary headers at the top and handle new utility headers like 'gmock' consistently with other utility headers. No other change was made. I did no manual edits, all of this is clang-format. This should allow other changes to have more clear and focused diffs, and is especially motivated by moving some headers into more focused libraries. llvm-svn: 304786
* [PDB] Fix use after free.Zachary Turner2017-06-031-35/+70
| | | | | | | | | | | | | | | | | | | | | | | Previously MappedBlockStream owned its own BumpPtrAllocator that it would allocate from when a read crossed a block boundary. This way it could still return the user a contiguous buffer of the requested size. However, It's not uncommon to open a stream, read some stuff, close it, and then save the information for later. After all, since the entire file is mapped into memory, the data should always be available as long as the file is open. Of course, the exception to this is when the data isn't *in* the file, but rather in some buffer that we temporarily allocated to present this contiguous view. And this buffer would get destroyed as soon as the strema was closed. The fix here is to force the user to specify the allocator, this way it can provide an allocator that has whatever lifetime it chooses. Differential Revision: https://reviews.llvm.org/D33858 llvm-svn: 304623
* Reverted r303602, as it will be fixed in gtest.Galina Kistanova2017-05-301-8/+4
| | | | llvm-svn: 304184
* Recommit "[DWARF] - Make collectAddressRanges() return section index in ↵George Rimar2017-05-271-6/+6
| | | | | | | | | | | | | | | | | | | | | | addition to Low/High PC" With fix of uninitialized variable. Original commit message: This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 304078
* Revert r304002 "[DWARF] - Make collectAddressRanges() return section index ↵George Rimar2017-05-261-6/+6
| | | | | | | | in addition to Low/High PC" Revert it again. Now another bot unhappy: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/8750 llvm-svn: 304011
* [DWARF] - Make collectAddressRanges() return section index in addition to ↵George Rimar2017-05-261-6/+6
| | | | | | | | | | | | | | | | | | Low/High PC This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 304002
* Revert "[DWARF] - Make collectAddressRanges() return section index in ↵George Rimar2017-05-261-6/+6
| | | | | | | | | | | | addition to Low/High PC" Broked BB again: TEST 'LLVM :: DebugInfo/X86/dbg-value-regmask-clobber.ll' FAILED ... LLVM ERROR: Section was outside of section table. llvm-svn: 303984
* Recommit r303978 "[DWARF] - Make collectAddressRanges() return section index ↵George Rimar2017-05-261-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | in addition to Low/High PC" With fix of test compilation. Initial commit message: This change is intended to use for LLD in D33183. Problem we have in LLD when building .gdb_index is that we need to know section which address range belongs to. Previously it was solved on LLD side by providing fake section addresses with use of llvm::LoadedObjectInfo interface. We assigned file offsets as addressed. Then after obtaining ranges lists, for each range we had to find section ID's. That not only was slow, but also complicated implementation and was the reason of incorrect behavior when sections share the same offsets, like D33176 shows. This patch makes DWARF parsers to return section index as well. That solves problem mentioned above. Differential revision: https://reviews.llvm.org/D33184 llvm-svn: 303983
* [CV Type Merging] Find nested type indices faster.Zachary Turner2017-05-253-0/+506
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merging two type streams is one of the most time consuming parts of generating a PDB, and as such it needs to be as fast as possible. The visitor abstractions used for interoperating nicely with many different types of inputs and outputs have been used widely and help greatly for testability and implementing tools, but the abstractions build up and get in the way of performance. This patch removes all of the visitation stuff from the type stream merger, essentially re-inventing the leaf / member switch and loop, but at a very low level. This allows us many other optimizations, such as not actually deserializing *any* records (even member records which don't describe their own length), as the operation of "figure out how long this record is" is somewhat faster than "figure out how long this record *and* get all its fields out". Furthermore, whereas before we had to deserialize, re-write type indices, then re-serialize, now we don't have to do any of those 3 steps. We just find out where the type indices are and pull them directly out of the byte stream and re-write them. This is worth a 50-60% performance increase. On top of all other optimizations that have been applied this week, I now get the following numbers when linking lld.exe and lld.pdb MSVC: 25.67s Before This Patch: 18.59s After This Patch: 8.92s So this is a huge performance win. Differential Revision: https://reviews.llvm.org/D33564 llvm-svn: 303935
* Fix a bug in MappedBlockStream.Zachary Turner2017-05-251-26/+25
| | | | | | | | | | It was using the number of blocks of the entire PDB file as the number of blocks of each stream that was created. This was only an issue in the readLongestContiguousChunk function, which was never called prior. This bug surfaced when I updated an algorithm to use this function and the algorithm broke. llvm-svn: 303916
* Cosmetic. Added braces to address gcc warning: suggest explicit braces to ↵Galina Kistanova2017-05-231-4/+8
| | | | | | avoid ambiguous 'else' [-Wdangling-else]. llvm-svn: 303602
* Resubmit "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-44/+39
| | | | | | | | | | | | This was originally reverted because it was a breaking a bunch of bots and the breakage was not surfacing on Windows. After much head-scratching this was ultimately traced back to a bug in the lit test runner related to its pipe handling. Now that the bug in lit is fixed, Windows correctly reports these test failures, and as such I have finally (hopefully) fixed all of them in this patch. llvm-svn: 303446
* Revert "[CodeView] Provide a common interface for type collections."Zachary Turner2017-05-191-39/+44
| | | | | | | | | | | | | | | | | | This is a squash of ~5 reverts of, well, pretty much everything I did today. Something is seriously broken with lit on Windows right now, and as a result assertions that fire in tests are triggering failures. I've been breaking non-Windows bots all day which has seriously confused me because all my tests have been passing, and after running lit with -a to view the output even on successful runs, I find out that the tool is crashing and yet lit is still reporting it as a success! At this point I don't even know where to start, so rather than leave the tree broken for who knows how long, I will get this back to green, and then once lit is fixed on Windows, hopefully hopefully fix the remaining set of problems for real. llvm-svn: 303409
* [CodeView] Provide a common interface for type collections.Zachary Turner2017-05-181-44/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now we have multiple notions of things that represent collections of types. Most commonly used are TypeDatabase, which is supposed to keep mappings from TypeIndex to type name when reading a type stream, which happens when reading PDBs. And also TypeTableBuilder, which is used to build up a collection of types dynamically which we will later serialize (i.e. when writing PDBs). But often you just want to do some operation on a collection of types, and you may want to do the same operation on any kind of collection. For example, you might want to merge two TypeTableBuilders or you might want to merge two type streams that you loaded from various files. This dichotomy between reading and writing is responsible for a lot of the existing code duplication and overlapping responsibilities in the existing CodeView library classes. For example, after building up a TypeTableBuilder with a bunch of type records, if we want to dump it we have to re-invent a bunch of extra glue because our dumper takes a TypeDatabase or a CVTypeArray, which are both incompatible with TypeTableBuilder. This patch introduces an abstract base class called TypeCollection which is shared between the various type collection like things. Wherever we previously stored a TypeDatabase& in some common class, we now store a TypeCollection&. The advantage of this is that all the details of how the collection are implemented, such as lazy deserialization of partial type streams, is completely transparent and you can just treat any collection of types the same regardless of where it came from. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303388
* [CodeView] Simplify the use of visiting type records & streams.Zachary Turner2017-05-172-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is often a lot of boilerplate code required to visit a type record or type stream. The #1 use case is that you have a sequence of bytes that represent one or more records, and you want to deserialize each one, switch on it, and call a callback with the deserialized record that the user can examine. Currently this requires at least 6 lines of code: codeview::TypeVisitorCallbackPipeline Pipeline; Pipeline.addCallbackToPipeline(Deserializer); Pipeline.addCallbackToPipeline(MyCallbacks); codeview::CVTypeVisitor Visitor(Pipeline); consumeError(Visitor.visitTypeRecord(Record)); With this patch, it becomes one line of code: consumeError(codeview::visitTypeRecord(Record, MyCallbacks)); This is done by having the deserialization happen internally inside of the visitTypeRecord function. Since this is occasionally not desirable, the function provides a 3rd parameter that can be used to change this behavior. Hopefully this can significantly reduce the barrier to entry to using the visitation infrastructure. Differential Revision: https://reviews.llvm.org/D33245 llvm-svn: 303271
* [CodeView] Silence some -Wsign-compare warningsJustin Bogner2017-05-131-10/+10
| | | | llvm-svn: 302971
* [CodeView] Add a random access type visitor.Zachary Turner2017-05-124-1/+426
| | | | | | | | | | | | This adds a visitor that is capable of accessing type records randomly and caching intermediate results that it learns about during partial linear scans. This yields amortized O(1) access to a type stream even though type streams cannot normally be indexed. Differential Revision: https://reviews.llvm.org/D33009 llvm-svn: 302936
* Delete dead function causing compilation failure.Zachary Turner2017-05-031-6/+0
| | | | llvm-svn: 302057
* [llvm-readobj] Update readobj to re-use parsing code.Zachary Turner2017-05-032-6/+25
| | | | | | | | | | llvm-readobj hand rolls some CodeView parsing code for string tables, so this patch updates it to re-use some of the newly introduced parsing code in LLVMDebugInfoCodeView. Differential Revision: https://reviews.llvm.org/D32772 llvm-svn: 302052
* Resubmit r301986 and r301987 "Add codeview::StringTable"Zachary Turner2017-05-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | This was reverted due to a "missing" file, but in reality what happened was that I renamed a file, and then due to a merge conflict both the old file and the new file got added to the repository. This led to an unused cpp file being in the repo and not referenced by any CMakeLists.txt but #including a .h file that wasn't in the repo. In an even more unfortunate coincidence, CMake didn't report the unused cpp file because it was in a subdirectory of the folder with the CMakeLists.txt, and not in the same directory as any CMakeLists.txt. The presence of the unused file was then breaking certain tools that determine file lists by globbing rather than by what's specified in CMakeLists.txt In any case, the fix is to just remove the unused file from the patch set. llvm-svn: 302042
* Verify that no compile units share the same line table in "llvm-dwarfdump ↵Greg Clayton2017-05-031-0/+81
| | | | | | | | | | --verify" Check to make sure no compile units have the same DW_AT_stmt_list values. Report a verification error if they do. Differential Revision: https://reviews.llvm.org/D32771 llvm-svn: 302039
* Revert r301986 (and subsequent r301987).Daniel Jasper2017-05-031-2/+2
| | | | | | | | | The patch is failing to add StringTableStreamBuilder.h, but that isn't even discovered because the corresponding StringTableStreamBuilder.cpp isn't added to any CMakeLists.txt file and thus never built. I think this patch is just incomplete. llvm-svn: 302002
* Make codeview::StringTable.Zachary Turner2017-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | Previously we had knowledge of how to serialize and deserialize a string table inside of DebugInfo/PDB, but the string table that it serializes contains a piece that is actually considered CodeView and can appear outside of a PDB. We already have logic in llvm-readobj and MCCodeView to read and write this format, so it doesn't make sense to duplicate the logic in DebugInfoPDB as well. This patch makes codeview::StringTable (for writing) and codeview::StringTableRef (for reading), updates DebugInfoPDB to use these classes for its own writing, and updates llvm-readobj to additionally use StringTableRef for reading. It's a bit more difficult to get MCCodeView to use this for writing, but it's a logical next step. llvm-svn: 301986
* Add line table verification to lldb-dwarfdump --verifyGreg Clayton2017-05-021-73/+170
| | | | | | | | | | | | This patch verifies the .debug_line: - verify all addresses in a line table sequence have ascending addresses - verify that all line table file indexes are valid Unit tests added for both cases. Differential Revision: https://reviews.llvm.org/D32765 llvm-svn: 301984
* Verify that all references point to actual DIEs in "llvm-dwarfdump --verify"Greg Clayton2017-05-021-0/+56
| | | | | | | | | | LTO and other fancy linking previously led to DWARF that contained invalid references. We already validate that CU relative references fall into the CU, and the DW_FORM_ref_addr references fall inside the .debug_info section, but we didn't validate that the references pointed to correct DIE offsets. This new verification will ensure that all references refer to actual DIEs and not an offset in between. This caught a bug in DWARFUnit::getDIEForOffset() where if you gave it any offset, it would match the DIE that mathes the offset _or_ the next DIE. This has been fixed. Differential Revision: https://reviews.llvm.org/D32722 llvm-svn: 301971
* Rename pdb::StringTable -> pdb::PDBStringTable.Zachary Turner2017-05-021-4/+4
| | | | | | | | With the forthcoming codeview::StringTable which a pdb::StringTable would hold an instance of as one member, this ambiguity becomes confusing. Rename to PDBStringTable to avoid this. llvm-svn: 301948
* Adds initial llvm-dwarfdump --verify support with unit tests.Greg Clayton2017-05-011-0/+241
| | | | | | | | | | | | | | | | | | lldb-dwarfdump gets a new "--verify" option that will verify a single file's DWARF debug info and will print out any errors that it finds. It will return an non-zero exit status if verification fails, and a zero exit status if verification succeeds. Adding the --quiet option will suppress any output the STDOUT or STDERR. The first part of the verify does the following: - verifies that all CU relative references (DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata) have valid CU offsets - verifies that all DW_FORM_ref_addr references have valid .debug_info offsets - verifies that all DW_AT_ranges attributes have valid .debug_ranges offsets - verifies that all DW_AT_stmt_list attributes have valid .debug_line offsets - verifies that all DW_FORM_strp attributes have valid .debug_str offsets Unit tests were added for each of the above cases. Differential Revision: https://reviews.llvm.org/D32707 llvm-svn: 301844
* Remove the unnecessary virtual dtor from the DIEUnit hierarchy (in favor of ↵David Blaikie2017-04-221-1/+1
| | | | | | | | | protected dtor in the base, final derived classes with public non-virtual dtors) These objects are never polymorphically owned/destroyed, so the virtual dtor was unnecessary. llvm-svn: 301068
* [DWARF] Versioning for DWARF constants; verify FORMsPaul Robinson2017-04-201-8/+14
| | | | | | | | | | | | | Associate the version-when-defined with definitions of standard DWARF constants. Identify the "vendor" for DWARF extensions. Use this information to verify FORMs in .debug_abbrev are defined as of the DWARF version specified in the associated unit. Removed two tests that had specified DWARF v1 (which essentially does not exist). Differential Revision: http://reviews.llvm.org/D30785 llvm-svn: 300875
* [llvm-pdbdump] More advanced class definition dumping.Zachary Turner2017-04-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Previously the dumping of class definitions was very primitive, and it made it hard to do more than the most trivial of output formats when dumping. As such, we would only dump one line for each field, and then dump non-layout items like nested types and enums. With this patch, we do a complete analysis of the object hierarchy including aggregate types, bases, virtual bases, vftable analysis, etc. The only immediately visible effects of this are that a) we can now dump a line for the vfptr where before we would treat that as padding, and b) we now don't treat virtual bases that come at the end of a class as padding since we have a more detailed analysis of the class's storage usage. In subsequent patches, we should be able to use this analysis to display a complete graphical view of a class's layout including recursing arbitrarily deep into an object's base class / aggregate member hierarchy. llvm-svn: 300133
* Fix llvm-symbolizer to navigate both DW_AT_abstract_origin and ↵David Blaikie2017-03-131-12/+18
| | | | | | | | | DW_AT_specification in a single chain In a recent refactoring (r291959) this regressed to only following one or the other, not both, in a single chain. llvm-svn: 297676
* [DWARF] NFC. A few bits of minor code cleanup.Chris Bieneman2017-03-063-13/+0
| | | | | | | | David Blaikie pointed out that the `setForceChildren` API is no longer needed and should be removed from the DWARF Generator APIs. Also the DWARFDebugInfoTest file had some copy pasted comments that are not relevant. I've removed them. llvm-svn: 297056
* [ObjectYAML] [DWARF] Abstract DWARF Initial Length valuesChris Bieneman2017-03-031-1/+2
| | | | | | | | In the DWARF 4 Spec section 7.2.2, data in many DWARF sections, and some DWARF structures start with "Initial Length Values", which are a 32-bit length, and an optional 64-bit length if the 32 bit value == UINT32_MAX. This patch abstracts the Initial Length type in YAML, and extends its use to all the DWARF structures that are supported in the DWARFYAML code that have Initial Length values. llvm-svn: 296911
* [Support] Move Stream library from MSF -> Support.Zachary Turner2017-03-025-721/+10
| | | | | | | | | | After several smaller patches to get most of the core improvements finished up, this patch is a straight move and header fixup of the source. Differential Revision: https://reviews.llvm.org/D30266 llvm-svn: 296810
* [DebugInfo] [DWARFv5] Unique abbrevs for DIEs with different implicit_const ↵Victor Leschuk2017-03-011-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | values Take DW_FORM_implicit_const attribute value into account when profiling DIEAbbrevData. Currently if we have two similar types with implicit_const attributes and different values we end up with only one abbrev in .debug_abbrev section. For example consider two structures: S1 with implicit_const attribute ATTR and value VAL1 and S2 with implicit_const ATTR and value VAL2. The .debug_abbrev section will contain only 1 related record: [N] DW_TAG_structure_type DW_CHILDREN_yes DW_AT_ATTR DW_FORM_implicit_const VAL1 // .... This is incorrect as struct S2 (with VAL2) will use abbrev record with VAL1. With this patch we will have two different abbreviations here: [N] DW_TAG_structure_type DW_CHILDREN_yes DW_AT_ATTR DW_FORM_implicit_const VAL1 // .... [M] DW_TAG_structure_type DW_CHILDREN_yes DW_AT_ATTR DW_FORM_implicit_const VAL2 // .... llvm-svn: 296691
* Re-enable BinaryStreamTest.StreamReaderObject.Zachary Turner2017-03-011-10/+18
| | | | | | | This was failing because I was using memcmp to compare two objects that included padding bytes, which were uninitialized. llvm-svn: 296681
* Disable BinaryStreamTest.StreamReaderObject.Zachary Turner2017-03-011-1/+1
| | | | llvm-svn: 296672
* [PDB] Fix and re-enable BinaryStreamArray test.Zachary Turner2017-03-011-36/+38
| | | | | | | | | | | This was due to the test stream choosing an arbitrary partition index for introducing the discontinuity rather than choosing an index that would be correctly aligned for the type of data. Also added an assertion into FixedStreamArray so that this will be caught on all bots in the future, and not just the UBSan bot. llvm-svn: 296661
* [PDB] Re-add BinaryStreamTest.Zachary Turner2017-03-012-0/+701
| | | | | | | | This re-adds all the binary stream tests. This was reverted due to some misaligned reads. For now the offending test is disabled while I investigate. llvm-svn: 296643
* Remove unittests/DebugInfo/PDB/BinaryStreamTest.cpp (from r296555)Vedant Kumar2017-03-012-701/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It breaks the ToT UBSan bots: /Users/vk/Desktop/llvm/include/llvm/DebugInfo/MSF/BinaryStreamArray.h:246:12: runtime error: reference binding to misaligned address 0x7f925540939a for type 'const int', which requires 4 byte alignment 0x7f925540939a: note: pointer points here 05 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 70 98 50 06 01 00 ^ 0 DebugInfoPDBTests 0x0000000106263cbd llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 45 1 DebugInfoPDBTests 0x00000001062628ff llvm::sys::RunSignalHandlers() + 159 2 DebugInfoPDBTests 0x0000000106264593 SignalHandler(int) + 179 3 libsystem_platform.dylib 0x0000000107bb3fba _sigtramp + 26 4 libsystem_pthread.dylib 0x0000000107bd82c8 _pthread_keys + 9720 5 libsystem_c.dylib 0x0000000107947f83 abort + 127 6 libclang_rt.ubsan_osx_dynamic.dylib 0x0000000106bb5fc2 __sanitizer::Abort() + 66 7 DebugInfoPDBTests 0x000000010613f880 llvm::FixedStreamArrayIterator<int>::operator+=(long) + 0 8 DebugInfoPDBTests 0x000000010613f615 llvm::FixedStreamArrayIterator<int>::operator*() const + 37 9 DebugInfoPDBTests 0x000000010613f3cb std::__1::enable_if<__is_forward_iterator<llvm::FixedStreamArrayIterator<int> >::value, void>::type std::__1::vector<int, std::__1::allocator<int> >::__construct_at_end<llvm::FixedStreamArrayIterator<int> >(llvm::FixedStreamArrayIterator<int>, llvm::FixedStreamArrayIterator<int>, unsigned long) + 251 10 DebugInfoPDBTests 0x000000010613f292 std::__1::vector<int, std::__1::allocator<int> >::vector<llvm::FixedStreamArrayIterator<int> >(llvm::FixedStreamArrayIterator<int>, std::__1::enable_if<(__is_forward_iterator<llvm::FixedStreamArrayIterator<int> >::value) && (is_constructible<int, std::__1::iterator_traits<llvm::FixedStreamArrayIterator<int> >::reference>::value), llvm::FixedStreamArrayIterator<int> >::type) + 226 11 DebugInfoPDBTests 0x000000010613ddb7 std::__1::vector<int, std::__1::allocator<int> >::vector<llvm::FixedStreamArrayIterator<int> >(llvm::FixedStreamArrayIterator<int>, std::__1::enable_if<(__is_forward_iterator<llvm::FixedStreamArrayIterator<int> >::value) && (is_constructible<int, std::__1::iterator_traits<llvm::FixedStreamArrayIterator<int> >::reference>::value), llvm::FixedStreamArrayIterator<int> >::type) + 87 12 DebugInfoPDBTests 0x000000010613d4af (anonymous namespace)::BinaryStreamTest_StreamReaderIntegerArray_Test::TestBody() + 1279 13 DebugInfoPDBTests 0x00000001062780f3 testing::Test::Run() + 179 14 DebugInfoPDBTests 0x0000000106279594 testing::TestInfo::Run() + 308 15 DebugInfoPDBTests 0x000000010627a6a3 testing::TestCase::Run() + 307 16 DebugInfoPDBTests 0x00000001062849d4 testing::internal::UnitTestImpl::RunAllTests() + 756 17 DebugInfoPDBTests 0x0000000106284558 testing::UnitTest::Run() + 152 18 DebugInfoPDBTests 0x0000000106266fa5 main + 117 19 libdyld.dylib 0x00000001078506a5 start + 1 zsh: abort ./unittests/DebugInfo/PDB/DebugInfoPDBTests llvm-svn: 296641
* [PDB] Remove use of std error codes.Zachary Turner2017-03-011-7/+6
| | | | | | | | | | I already created a BinaryStreamError class for this purpose, so update the code to use that on the remaining occurrences of errc values. This should also address the issue which led to r296583. llvm-svn: 296640
* (Rewroking r296581) PDB/BinaryStreamTest.cpp: Appease mingw to avoid ↵NAKAMURA Takumi2017-03-011-3/+4
| | | | | | | | | | | | std::errc::no_buffer_space. Unfortunately, mingw's libstdc++ doesn't provide winsock2 errors. That said, we should avoid raising OS-oriented error code in our code. For now, I suggest to define custom error from std::error_category. See also; https://reviews.llvm.org/D20592 llvm-svn: 296583
* Revert r296581, "PDB/BinaryStreamTest.cpp: Appease mingw to avoid ↵NAKAMURA Takumi2017-03-011-3/+3
| | | | | | | | std::errc::no_buffer_space." Wrong commit -- I have unstaged changes. llvm-svn: 296582
* PDB/BinaryStreamTest.cpp: Appease mingw to avoid std::errc::no_buffer_space.NAKAMURA Takumi2017-03-011-3/+3
| | | | | | | | | | Unfortunately, mingw's libstdc++ doesn't provide winsock2 errors. That said, we should avoid raising OS-oriented error code in our code. For now, I suggest to define custom error from std::error_category. See also; https://reviews.llvm.org/D20592 llvm-svn: 296581
* Move constexpr arrays out of class definition.Zachary Turner2017-03-011-3/+4
| | | | | | GCC Linker doesn't seem to like this. llvm-svn: 296560
* Fix signed / unsigned comparison warning.Zachary Turner2017-03-011-1/+1
| | | | llvm-svn: 296557
* [PDB] Add an additional test for BinaryStreamRef.Zachary Turner2017-03-011-2/+58
| | | | | | | | | | | A bug was uncovered where if you have a StreamRef whose ViewOffset is > 0, then when you call readLongestContiguousChunk it will succeed even when it shouldn't, and it always return you a buffer that was taken as if the ViewOffset was 0. Fixed this bug and added a test for it. llvm-svn: 296556
* [PDB] Add tests for BinaryStream.Zachary Turner2017-03-012-0/+644
| | | | llvm-svn: 296555
* [DWARFv5] Emit new unit header format.Paul Robinson2017-02-281-2/+8
| | | | | | | | | Requesting DWARF v5 will now get you the new compile-unit and type-unit headers. llvm-dwarfdump will also recognize them. Differential Revision: http://reviews.llvm.org/D30206 llvm-svn: 296514
* [PDB] Add BinaryStreamError.Zachary Turner2017-02-281-6/+6
| | | | | | | This migrates the stream code away from MSFError to using its own custom Error class. llvm-svn: 296494
OpenPOWER on IntegriCloud