summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/BinaryStreamReader.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add a BinarySubstreamRef, and a method to read one.Zachary Turner2017-06-231-0/+6
| | | | | | | | | This is essentially just a BinaryStreamRef packaged with an offset and the logic for reading one is no different than the logic for reading a BinaryStreamRef, except that we save the current offset. llvm-svn: 306122
* Adding parsing ability for .res file.Eric Beckmann2017-05-301-0/+20
| | | | | | | | Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33566 llvm-svn: 304225
* Make BinaryStreamReader::readCString a bit faster.Zachary Turner2017-05-251-13/+14
| | | | | | | | | | | | | | | | | | | | | Previously it would do a character by character search for a null terminator, to account for the fact that an arbitrary stream need not store its data contiguously so you couldn't just do a memchr. However, the stream API has a function which will return the longest contiguous chunk without doing a copy, and by using this function we can do a memchr on the individual chunks. For certain types of streams like data from object files etc, this is guaranteed to find the null terminator with only a single memchr, but even with discontiguous streams such as MappedBlockStream, it's rare that any given string will cross a block boundary, so even those will almost always be satisfied with a single memchr. This optimization is worth a 10-12% reduction in link time (4.2 seconds -> 3.75 seconds) Differential Revision: https://reviews.llvm.org/D33503 llvm-svn: 303918
* Add some helpers for manipulating BinaryStreamRefs.Zachary Turner2017-05-171-0/+5
| | | | llvm-svn: 303297
* [BinaryStream] Reduce the amount of boiler plate needed to use.Zachary Turner2017-05-171-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Often you have an array and you just want to use it. With the current design, you have to first construct a `BinaryByteStream`, and then create a `BinaryStreamRef` from it. Worse, the `BinaryStreamRef` holds a pointer to the `BinaryByteStream`, so you can't just create a temporary one to appease the compiler, you have to actually hold onto both the `ArrayRef` as well as the `BinaryByteStream` *AND* the `BinaryStreamReader` on top of that. This makes for very cumbersome code, often requiring one to store a `BinaryByteStream` in a class just to circumvent this. At the cost of some added complexity (not exposed to users, but internal to the library), we can do better than this. This patch allows us to construct `BinaryStreamReaders` and `BinaryStreamWriters` directly from source data (e.g. `StringRef`, `MutableArrayRef<uint8_t>`, etc). Not only does this reduce the amount of code you have to type and make it more obvious how to use it, but it solves real lifetime issues when it's inconvenient to hold onto a `BinaryByteStream` for a long time. The additional complexity is in the form of an added layer of indirection. Whereas before we simply stored a `BinaryStream*` in the ref, we now store both a `BinaryStream*` **and** a `std::shared_ptr<BinaryStream>`. When the user wants to construct a `BinaryStreamRef` directly from an `ArrayRef` etc, we allocate an internal object that holds ownership over a `BinaryByteStream` and forwards all calls, and store this in the `shared_ptr<>`. This also maintains the ref semantics, as you can copy it by value and references refer to the same underlying stream -- the one being held in the object stored in the `shared_ptr`. Differential Revision: https://reviews.llvm.org/D33293 llvm-svn: 303294
* Resubmit r301986 and r301987 "Add codeview::StringTable"Zachary Turner2017-05-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | 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-13/+0
| | | | | | | | | 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-0/+13
| | | | | | | | | | | | | | | | | | | | 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
* [Support] Move Stream library from MSF -> Support.Zachary Turner2017-03-021-0/+95
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
OpenPOWER on IntegriCloud