[PATCH] D23145: pdbdump: Write a free page map to page 1 or page 2.

[Zachary Turner via llvm-commits]

I think we should do it, but it's up to you. Even if we don't add a test
for the big pdb, we're still fixing this issue, since with a small pdb
using MappedBlockStream or not will be equivalent.

Btw, it should be very easy to test large pdb. Write some yaml by hand to
manually specify the file size in the MsfHeader section, then use the
DirectoryBlocks field to specify a large block number that would result in
a modification of page 2 of split fpm. Then run yaml2pdb on it and dump the
fpm of the result.

Anyway, I'll leave It's up to you, but it seems like just a few lines of
code change for a big gain

On Wed, Aug 3, 2016 at 5:41 PM Rui Ueyama <ruiu at google.com> wrote:

> Well, I could that if you want, but in order to test that we need a large
> PDB file for round-trip testing, and I'm afraid that that may probably
> trigger more issues than the existing stream 0 issue. So, I'd like to fix
> stream 0 bug first.
>
> On Wed, Aug 3, 2016 at 5:37 PM, Zachary Turner <zturner at google.com> wrote:
>
>> Any particular reason you don't want to support writing split fpms yet?
>> Just call `WritableMappedBlockStream::createFpmStream` and then writeBytes
>> on the result, and everything should just work
>> On Wed, Aug 3, 2016 at 5:30 PM Rui Ueyama <ruiu at google.com> wrote:
>>
>>> ruiu created this revision.
>>> ruiu added a reviewer: zturner.
>>> ruiu added a subscriber: llvm-commits.
>>>
>>> As I wrote in a comment, llvm-pdbdump seems to not be able to restore
>>> stream 0 correctly. That is why we get different results for empty.pdb
>>> and our pdb file.
>>>
>>> This patch is to write only one FPM. So it still cannot produce large
>>> PDBs which need more than one FPM page.
>>>
>>> https://reviews.llvm.org/D23145
>>>
>>> Files:
>>>   lib/DebugInfo/MSF/MSFBuilder.cpp
>>>   lib/DebugInfo/PDB/Raw/PDBFileBuilder.cpp
>>>   test/DebugInfo/PDB/pdbdump-readwrite.test
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160804/6f18438a/attachment.html>