[PATCH] D21157: [pdb] Improve StreamInterface to support writing
Zachary Turner via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 8 16:41:54 PDT 2016
zturner created this revision.
zturner added reviewers: ruiu, rnk, majnemer.
zturner added a subscriber: llvm-commits.
This adds support for writing to a `StreamInterface`, including a `MappedBlockStream` which might be discontiguous.
No code actually uses this yet, but I've added a bunch of unit tests to illustrate the idea and demonstrate that it works.
There were two unexpected complexities that arose with this patch.
First, due to the nature of how we need to allocate from a pool when a read breaks a stream boundary, things get complicated when you go and start writing. If you just write to the underlying stream (which could be discontiguous at the point you write), a person holding onto a pool pointer will now have a stale view of the contents.
Second, we previously assumed that any two reads from the same stream offset would have the same size (due to the nature of how streams are laid out as records that don't often change). This is a very inconvenient assumption when trying to write unit tests, where you may want to write something, read it back out, then write over it, then read it back out again. So I removed this assumption.
The result is somewhat convoluted, but the idea is this:
```
read:
1. try to read contiguously. If so, return it.
2. Otherwise check if there is a cached pool allocation
that is the same size or bigger than the request. If so, return it.
3. Otherwise make a new pool allocation for the given offset and
size, copy the data into it, and add it to the list of allocations for
this offset.
write:
1. Write all the data across the discontiguous sequence of blocks.
2. Iterate every cached allocation, looking for any allocation which
overlaps this request.
3. For those which overlap, memcpy the overlapped portion of the
cached allocation with the corresponding data from the new write
```
While this is O(n) in number of cached allocations, this is again most
common in tests, and will not be a frequent occurrence in real world
situations, so I think it's ok.
http://reviews.llvm.org/D21157
Files:
include/llvm/DebugInfo/CodeView/ByteStream.h
include/llvm/DebugInfo/CodeView/CodeViewError.h
include/llvm/DebugInfo/CodeView/StreamArray.h
include/llvm/DebugInfo/CodeView/StreamInterface.h
include/llvm/DebugInfo/CodeView/StreamRef.h
include/llvm/DebugInfo/CodeView/StreamWriter.h
include/llvm/DebugInfo/PDB/Raw/IPDBFile.h
include/llvm/DebugInfo/PDB/Raw/MappedBlockStream.h
include/llvm/DebugInfo/PDB/Raw/PDBFile.h
include/llvm/DebugInfo/PDB/Raw/RawError.h
include/llvm/Support/MathExtras.h
lib/DebugInfo/CodeView/ByteStream.cpp
lib/DebugInfo/CodeView/CMakeLists.txt
lib/DebugInfo/CodeView/CodeViewError.cpp
lib/DebugInfo/CodeView/StreamWriter.cpp
lib/DebugInfo/CodeView/TypeDumper.cpp
lib/DebugInfo/PDB/Raw/MappedBlockStream.cpp
lib/DebugInfo/PDB/Raw/PDBFile.cpp
lib/DebugInfo/PDB/Raw/RawError.cpp
tools/llvm-readobj/COFFDumper.cpp
unittests/DebugInfo/PDB/MappedBlockStreamTest.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D21157.60115.patch
Type: text/x-patch
Size: 34978 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160608/2357a4ab/attachment-0001.bin>
More information about the llvm-commits
mailing list