[llvm-bugs] [Bug 41712] New: PDB GUIDs are printed with incorrect byte order.

via llvm-bugs llvm-bugs at lists.llvm.org
Thu May 2 09:35:17 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=41712

            Bug ID: 41712
           Summary: PDB GUIDs are printed with incorrect byte order.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: zturner at google.com
                CC: amccarth at google.com, jdevlieghere at apple.com,
                    keith.walker at arm.com, llvm-bugs at lists.llvm.org,
                    nicolasweber at gmx.de,
                    paul_robinson at playstation.sony.com, rnk at google.com

In DebugInfo/CodeView/GUID.h we define the GUID structure like this:

struct GUID {
  uint8_t Guid[16];
};

Then when we print it, we just iterate the sequence of bytes and print each one
with dashes in the appropriate place.

In the Microsoft headers, GUID is defined like this:

typedef struct _GUID {
    unsigned long  Data1;
    unsigned short Data2;
    unsigned short Data3;
    unsigned char  Data4[ 8 ];
} GUID;

So the "standard" way of formatting a GUID will have the first 3 fields printed
in little-endian byte order.  We can see this in action with the following
commands:

$ llvm-readobj -coff-debug-directory foo.exe | grep PDBGUID
      PDBGUID: (66 ED A0 BF 54 10 96 42 9B 7B 29 28 7E 84 67 B1)

$ llvm-pdbutil dump -summary foo.pdb | grep GUID
  GUID: {66EDA0BF-5410-9642-9B7B-29287E8467B1}

So here we can see that we print the GUID in byte-order.

Now load this EXE in WinDbg:

0:000> !chksym foo
*** WARNING: Unable to verify checksum for foo.exe

foo.exe
    Timestamp: 5CCB1685
  SizeOfImage: 6B000
          pdb: C:\src\sandbox\foo.pdb
      pdb sig: BFA0ED66-1054-4296-9B7B-29287E8467B1

And we can see that the signature is printed as if the first 3 fields were
little endian integers, not just a sequence of bytes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190502/ec719241/attachment.html>


More information about the llvm-bugs mailing list