[PDB] Fix reading of clang-generated PDBs by CVDump.

Authored by zturner on Jun 21 2017, 6:07 PM.



If you dump a pdb to yaml, and then round-trip it back to a pdb, and run cvdump -l <file> on the new pdb, cvdump will generate output such as this.

Microsoft (R) Debugging Information Dumper  Version 14.00.23611
Copyright (C) Microsoft Corporation.  All rights reserved.


** Module: "d:\src\llvm\test\DebugInfo\PDB\Inputs\empty.obj"

Error: Line number corrupted: invalid file id 0
  <Unknown> (MD5), 0001:00000010-0000001A, line/addr pairs = 3

      5 00000010      6 00000013      7 00000018

Note the error message about the corrupted line number.

It turns out that the problem is that cvdump cannot find the /names stream (e.g. the global string table), and the reason it can't find the /names stream is because it doesn't understand the NameMap that we serialize which tells pdb consumers which stream has the string table.

Some experimentation shows that if we add items to the hash table in a specific order before serializing it, cvdump can read it. This suggests that we're using the wrong hash function, but it will take some deeper investigation to figure out how / why. For now, this at least allows cvdump to read our line information.

Diff Detail

zturner created this revision.Jun 21 2017, 6:07 PM
rnk accepted this revision.Jun 21 2017, 6:13 PM

lgtm =/

This revision is now accepted and ready to land.Jun 21 2017, 6:13 PM
amccarth added inline comments.Jun 22 2017, 7:57 AM
87 ↗(On Diff #103503)

Just to make sure I understand ... the old way iterated through everything in Mapping, and the new way iterates only through the three streams in OrderedStreamNames. Will there ever be anything in the Mapping besides those three streams?

zturner added inline comments.Jun 22 2017, 9:31 AM
87 ↗(On Diff #103503)

Not quite right. The new way still iterates through everything in Mapping. These 3 strings are the only 3 strings that were ever there to begin with. The difference is that when iterating Mapping, you can't guarantee the order the results will be returned in, so they were being returned in a different order. We still end up with the same hash table, we've just inserted the items in a determined ordering.

amccarth accepted this revision.Jun 22 2017, 10:05 AM

Thanks for the clarification.

This revision was automatically updated to reflect the committed changes.