Breakpad processor support for x86-64

[GoogleCodeExporter]

I got curious and installed Windows XP x64 in a VM, and found that the
Windows client code compiles just fine, and produces minidumps.  I then
spent some time hacking the processor code to recognize some basic info
about the minidump.  I didn't try to implement a stackwalker, especially
since the x86-64 ABI explicitly says that FPO is totally cool, and the x86
stackwalker kind of scares me, but I got the MDRawContextAMD64 filled in,
and some basic stuff around that, so at least you can use minidump_dump
with this patch and see some info about the dump.

Things to note:
1) MDRawContextAMD64 does *not* have context_flags as the first member.  Sucks.
2) There's probably some extra cruft in this patch due to indentation changes
3) the u_int128_t definition doesn't seem to match WinNT.h's M128 struct
definition, in that M128 is defined as roughly:
unsigned long long Low;
long long High;
and u_int128_t is:
u_int64_t high;
u_int64_t low;

Original issue reported on code.google.com by ted.mielczarek on 5 Jul 2007 at 4:00

Attachments:

• breakpad-amd64-basic.patch

[GoogleCodeExporter]

I caved and implemented a skeletal stackwalker, which doesn't actually work at 
all,
except it's enough to run minidump_stackwalk now, you just only get the top 
frame.

Original comment by ted.mielczarek on 5 Jul 2007 at 5:24

Attachments:

• breakpad-amd64-crummy-stackwalk.patch

[GoogleCodeExporter]

I am looking into making breakpad Linux client works for x86_64. Seems you have
already got something useful.

Original comment by lul...@gmail.com on 29 Jul 2007 at 2:20

[GoogleCodeExporter]

Checked in with review comments.  Needs more work to be truly usable, like a 
real
stack walker.

Original comment by ted.mielczarek on 31 Oct 2007 at 8:15

• Changed state: Fixed

[GoogleCodeExporter]

Hi Ted,

thanks for this patch!

Did you work on it since October? I noticed the status changed to Fixed while 
it's
not, obviously...

I got into something weird while using it. When generating the sym file for one 
of
our 64bit dlls, the symbol generator ended in an infinite loop. I debugged it 
and
found it has just processed the last symbol of the dll (I knew it was the last 
by
comparing with the 32bit version of the same dll). Did you notice something 
similar?
I don't know if I should log it as an issue as it's not using the regular 
version but
your patched one..

Ben

Original comment by benoit.l...@gmail.com on 22 Jan 2008 at 11:18

[GoogleCodeExporter]

Benoit:  this patch was checked in, but this doesn't really get you full x86-64
support.  It makes the processor code know about that architecture, but it 
doesn't
even contain working stack walking code.  I don't know that anyone has tested
dump_syms on x86-64, you might be on your own there.  I only compiled the 
exception
handling bits and generated a minidump with it.  You should file that as a 
separate
issue, this code is all checked in to trunk.

Original comment by ted.mielczarek on 22 Jan 2008 at 12:13