summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/DebugInfo/PDB
Commit message (Collapse)AuthorAgeFilesLines
* Inline a few CMake variables into their only uses.Nico Weber2018-05-141-5/+1
| | | | | | No behavior change. Makes unittests CMakeLists.txt files more self-consistent. llvm-svn: 332280
* [DebugInfoPDB] Add missing test for findSymbolByRVA and findSymbolByAddrAaron Smith2018-04-101-0/+9
| | | | llvm-svn: 329733
* [DebugInfoPDB] Add DIA implementation of findLineNumbersByRVAAaron Smith2018-03-261-0/+4
| | | | | | | This method is used to find line numbers for PDBSymbolData that have an invalid virtual address. llvm-svn: 328586
* [DebugInfoPDB] Add DIA implementation of addressForVA and addressForRVAAaron Smith2018-03-261-2/+8
| | | | | | These are used in finding line numbers for PDBSymbolData llvm-svn: 328585
* [DIA] Add IPDBSectionContrib interfaces and DIA implementationAaron Smith2018-03-221-0/+5
| | | | | | | | | | | | | | | | | | | | | To resolve symbol context at a particular address, we need to determine the compiland for the address. We are able to determine the parent compiland of PDBSymbolFunc, PDBSymbolTypeUDT, PDBSymbolTypeEnum symbols indirectly through line information. However no such information is availabile for PDBSymbolData, i.e. variables. The Section Contribution table from PDBs has information about each compiland's contribution to sections by address. For example, a piece of a contribution looks like, VA RelativeVA Sect No. Offset Length Compiland 14000087B0 000087B0 0001 000077B0 000000BB exe_main.obj So given an address, it's possible to determine its compiland with this information. llvm-svn: 328178
* [PDB] Don't ignore bucket 0 when writing the PDB string table.Zachary Turner2018-03-211-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | The hash table is a list of buckets, and the *value* stored in the bucket cannot be 0 since that is reserved. However, the code here was incorrectly skipping over the 0'th bucket entirely. The 0'th bucket is perfectly fine, just none of these buckets can contain the value 0. As a result, whenever there was a string where hash(S) % Size was equal to 0, we would write the value in the next bucket instead. We never caught this in our tests due to *another* bug, which is that we would iterate the entire list of buckets looking for the value, only using the hash value as a starting point. However, the real algorithm stops when it finds 0 in a bucket since it takes that to mean "the item is not in the hash table". The unit test is updated to carefully construct a set of hash values that will cause one item to hash to 0 mod bucket count, and the reader is also updated to return an error indicating that the item is not found when it encounters a 0 bucket. llvm-svn: 328162
* HashTableTest: squelch some "comparison of integers of different signs" warningsPavel Labath2018-03-161-9/+9
| | | | llvm-svn: 327701
* Fix structure alignment issue.Zachary Turner2018-03-151-4/+0
| | | | llvm-svn: 327666
* Refactor the PDB HashTable class.Zachary Turner2018-03-151-45/+100
| | | | | | | | | It previously only worked when the key and value types were both 4 byte integers. We now have a use case for a non trivial value type, so we need to extend it to support arbitrary value types, which means templatizing it. llvm-svn: 327647
* [DebugInfo] Add a new method IPDBSession::findLineNumbersBySectOffsetAaron Smith2018-03-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some PDB symbols do not have a valid VA or RVA but have Addr by Section and Offset. For example, a variable in thread-local storage has the following properties: get_addressOffset: 0 get_addressSection: 5 get_lexicalParentId: 2 get_name: g_tls get_symIndexId: 12 get_typeId: 4 get_dataKind: 6 get_symTag: 7 get_locationType: 2 This change provides a new method to locate line numbers by Section and Offset from those symbols. Reviewers: zturner, rnk, llvm-commits Subscribers: asmith, JDevlieghere Differential Revision: https://reviews.llvm.org/D44407 llvm-svn: 327601
* Implement pure virtual method to fix build.Zachary Turner2018-03-131-0/+5
| | | | llvm-svn: 327431
* [DebugInfoPDB] Add DIA implementation for getSrcLineOnTypeDefnAaron Smith2018-03-071-0/+5
| | | | | | | | | | | | | | Summary: This helps to determine the line number for a PDB type with definition Reviewers: zturner, llvm-commits, rnk Reviewed By: zturner Subscribers: rengolin, JDevlieghere Differential Revision: https://reviews.llvm.org/D44119 llvm-svn: 326857
* [PDB] Check the result of setLoadAddress()Aaron Smith2018-02-231-1/+1
| | | | | | | | | | | | Summary: Change setLoadAddress() to return true or false on failure. Reviewers: zturner, llvm-commits Reviewed By: zturner Differential Revision: https://reviews.llvm.org/D43638 llvm-svn: 325843
* [PDB] Add missing override to silence buildbotsAaron Smith2018-02-221-1/+1
| | | | llvm-svn: 325828
* [PDB] Implement more find methods for PDB symbolsAaron Smith2018-02-221-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add additional find methods on PDB raw symbols. findChildrenByAddr() findChildrenByVA() findInlineFramesByAddr() findInlineFramesByVA() findInlineLines() findInlineLinesByAddr() findInlineLinesByRVA() findInlineLinesByVA() Reviewers: zturner, llvm-commits Reviewed By: zturner Differential Revision: https://reviews.llvm.org/D43637 llvm-svn: 325824
* Silence an unsigned vs signed compare warning.Eric Christopher2018-02-161-7/+7
| | | | llvm-svn: 325402
* Fix emission of PDB string table.Zachary Turner2018-02-161-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was originally reported as a bug with the symptom being "cvdump crashes when printing an LLD-linked PDB that has an S_FILESTATIC record in it". After some additional investigation, I determined that this was a symptom of a larger problem, and in fact the real problem was in the way we emitted the global PDB string table. As evidence of this, you can take any lld-generated PDB, run cvdump -stringtable on it, and it would return no results. My hypothesis was that cvdump could not *find* the string table to begin with. Normally it would do this by looking in the "named stream map", finding the string /names, and using its value as the stream index. If this lookup fails, then cvdump would fail to load the string table. To test this hypothesis, I looked at the name stream map generated by a link.exe PDB, and I emitted exactly those bytes into an LLD-generated PDB. Suddenly, cvdump could read our string table! This code has always been hacky and we knew there was something we didn't understand. After all, there were some comments to the effect of "we have to emit strings in a specific order, otherwise things don't work". The key to fixing this was finally understanding this. The way it works is that it makes use of a generic serializable hash map that maps integers to other integers. In this case, the "key" is the offset into a buffer, and the value is the stream number. If you index into the buffer at the offset specified by a given key, you find the name. The underlying cause of all these problems is that we were using the identity function for the hash. i.e. if a string's offset in the buffer was 12, the hash value was 12. Instead, we need to hash the string *at that offset*. There is an additional catch, in that we have to compute the hash as a uint32 and then truncate it to uint16. Making this work is a little bit annoying, because we use the same hash table in other places as well, and normally just using the identity function for the hash function is actually what's desired. I'm not totally happy with the template goo I came up with, but it works in any case. The reason we never found this bug through our own testing is because we were building a /parallel/ hash table (in the form of an llvm::StringMap<>) and doing all of our lookups and "real" hash table work against that. I deleted all of that code and now everything goes through the real hash table. Then, to test it, I added a unit test which adds 7 strings and queries the associated values. I test every possible insertion order permutation of these 7 strings, to verify that it really does work as expected. Differential Revision: https://reviews.llvm.org/D43326 llvm-svn: 325386
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [DebugInfo/PDB] Adding getUndecoratedNameEx and IPDB interfaces for ↵Aaron Smith2017-11-161-0/+9
| | | | | | | | | | | IDiaEnumTables and IDiaTable. Initial changes to support debugging PE/COFF files with LLDB on Windows through DIA SDK. There is another set of changes required on the LLDB side before this does anything. Differential Revision: https://reviews.llvm.org/D39517 llvm-svn: 318403
* [MSF] Move MSF unit tests to their own unittest target.Zachary Turner2017-08-023-862/+0
| | | | llvm-svn: 309895
* [pdbutil] Add a command to dump the FPM.Zachary Turner2017-08-021-1/+0
| | | | | | | | | | | | | | Recently problems have been discovered in the way we write the FPM (free page map). In order to fix this, we first need to establish a baseline about what a correct FPM looks like using an MSVC generated PDB, so that we can then make our own generated PDBs match. And in order to do this, the dumper needs a mode where it can dump an FPM so that we can write tests for it. This patch adds a command to dump the FPM, as well as a test against a known-good PDB. llvm-svn: 309894
* [codeview] Remove TypeServerHandler and PDBTypeServerHandlerReid Kleckner2017-07-172-185/+1
| | | | | | | | | | | | | | | | | Summary: Instead of wiring these through the CVTypeVisitor interface, clients should inspect the CVTypeArray before visiting it and potentially load up the type server's TPI stream if they need it. No tests relied on this functionality because LLD was the only client. Reviewers: ruiu Subscribers: mgorny, hiraditya, zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D35394 llvm-svn: 308212
* Make IPDBSession::getGlobalScope a non-const methodAdrian McCarthy2017-06-221-3/+1
| | | | | | | | | | | | There doesn't seem to be a compelling reason why this method should be const other than it was possible with the DIA implementation. The native session is going to act as a symbol factory and cache. This could be acheived with mutable (and the existing const_cast), but it seems cleaner to accept that this method affects the state of the session. This change eliminates an existing const_cast. llvm-svn: 306041
* Don't include TestingSupport in LLVM_LINK_COMPONENTS.Zachary Turner2017-06-141-1/+2
| | | | | | | | Instead use target_link_libraries directly. Thanks to Juergen Ributzka for the suggestion, which fixes an issue when llvm is configured with no targets. llvm-svn: 305421
* [gtest] Create a shared include directory for gtest utilities.Zachary Turner2017-06-147-195/+148
| | | | | | | | | | | | | | | | | | | | | | | Many times unit tests for different libraries would like to use the same helper functions for checking common types of errors. This patch adds a common library with helpers for testing things in Support, and introduces helpers in here for integrating the llvm::Error and llvm::Expected<T> classes with gtest and gmock. Normally, we would just be able to write: EXPECT_THAT(someFunction(), succeeded()); but due to some quirks in llvm::Error's move semantics, gmock doesn't make this easy, so two macros EXPECT_THAT_ERROR() and EXPECT_THAT_EXPECTED() are introduced to gloss over the difficulties. Consider this an exception, and possibly only temporary as we look for ways to improve this. Differential Revision: https://reviews.llvm.org/D33059 llvm-svn: 305395
* [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
* 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
* [CodeView] Simplify the use of visiting type records & streams.Zachary Turner2017-05-171-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* 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
* [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
* [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
* 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
* [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