search

getsentry / pdb

A parser for Microsoft PDB (Program Database) debugging information
https://docs.rs/pdb/
Apache License 2.0
385 stars 69 forks source link

Wrong PDBInformation GUID endianness #24

Closed jan-auer closed 6 years ago

jan-auer commented 6 years ago

The endianness of the guid in PDBInformation seems to be off compared to llvm-pdbutil, specifically its first three fields:

llvm-pdbutil:  98D1EFE8-6EF8-FE45-9DDB-E11382B5D1C9
willglynn/pdb: e8efd198-f86e-45fe-9ddb-e11382b5d1c9

The problem seems to originate in manually parsing the UUID fields with platform-endianness here: https://github.com/willglynn/pdb/blob/7947bcc3cc1f8f7ab2952155f83ed1bd8dd0eb05/src/pdbi.rs#L159-L164

After changing this to Uuid::from_bytes(buf.take(16)?), the output is correct. I'll submit a patch shortly, after running some more tests. I did not verify that llvm-pdbutil is correct in this case, but I'm assuming so foolishly 😄

For testing, I was using the Electron v2.0.11 x64 PDB. You can obtain an archive here (sorry, it's rather large).

willglynn commented 6 years ago

Hmm, I thought I had a reason for doing this the long way. Is there a Microsoft tool that can confirm the intended byte order, either in the PDB or in the corresponding PE executable?

jan-auer commented 6 years ago

Sorry for not checking this earlier. Microsoft's GUIDs specify little endian representation of the fields indeed, which means your initial implementation was correct. dumpbin /headers electron.exe showed the original GUID.

Surprisingly, llvm-pdbutil is buggy. I'll go ahead and put in a bug report there. Thanks for double-checking this!