Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
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
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:
This issue was closed by revision r89.
Original comment by moo...@gmail.com
on 18 Apr 2012 at 10:59
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:
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
Original issue reported on code.google.com by
matthew....@gmail.com
on 29 Mar 2012 at 2:01