ohio813 / pdbparse

Automatically exported from code.google.com/p/pdbparse
0 stars 0 forks source link

Incorrect output from print_ctypes.py #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Get ntdll.pdb for Windows 7 x64
2. Run the example: print_ctypes.py -f ntdll.pdb

What is the expected output? What do you see instead?
The definition for LARGE_INTEGER is wrong. The description from Microsoft (see 
http://msdn.microsoft.com/en-us/library/aa383713(v=vs.85).aspx) indicates an 8 
byte union. However, the output from pdbparse shows a 16 byte union.

pdbparse defines this:
union _LARGE_INTEGER {
  ULONG LowPart;
  LONG  HighPart;
  union {
  struct {
    ULONG LowPart;
    LONG  HighPart;
   } u ;
  LONGLONG QuadPart ;
  };

};

What version of the product are you using? On what operating system?
SVN repository HEAD as of 2012-03-28.

Please provide any additional information below.
This behavior probably affects other definitions.

Original issue reported on code.google.com by matthew....@gmail.com on 29 Mar 2012 at 2:01

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
My original description of the problem is wrong. The problem with pdbparse's 
output is that LI.LowPart and LI.HighPart (LI means _LARGE_INTEGER) both have 
an offset of 0 within the union, whereas in the Microsoft definition they have 
offsets of 0 and 4, respectively.

A small correction: _LARGE_INTEGER is defined as a union, but its forward 
declaration from pdbparse indicates it is a struct.

Here's Microsoft's definition (since the link in my original post isn't working 
now):
typedef union _LARGE_INTEGER {
  struct {
    DWORD LowPart;
    LONG  HighPart;
  };
  struct {
    DWORD LowPart;
    LONG  HighPart;
  } u;
  LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

Original comment by matthew....@gmail.com on 30 Mar 2012 at 2:16

GoogleCodeExporter commented 9 years ago
I haven't heard anything back on this, so here's a patch that fixes the 
problem. Beware that it is ugly!

--Matt

Original comment by matthew....@gmail.com on 17 Apr 2012 at 5:37

Attachments:

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r89.

Original comment by moo...@gmail.com on 18 Apr 2012 at 10:59

GoogleCodeExporter commented 9 years ago
The mods that I submitted still had issues. Try this updated print_ctypes.py 
script for more improvements.

There are a few outstanding issues:
-getting the architecture pointer size from pdb.STREAM_DBI does not work 
reliably
-nested structs/unions confuse the current algorithm

Original comment by matthew....@gmail.com on 24 May 2012 at 5:34

Attachments:

GoogleCodeExporter commented 9 years ago
Hi,

This looks good; I've committed it (r91). Also, could you test the STREAM_DBI 
issue with a file that was causing trouble? It was formerly missing a "default" 
case, which has since been added -- note that in some cases it's still not 
possible to get the pointer size automatically, though.

Original comment by moo...@gmail.com on 22 Jun 2012 at 12:14