[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