ykagan / google-breakpad

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

MinGW support for the Windows client #436

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,

Attached is a patch to include some MinGW support for the Windows client:

1. The purecall hook support is MSVC-only, so guard it with #defines.
2. Sometimes, MinGW's C++ headers get seriously confused if you #include the 
Windows header files first (e.g. __out is used internally, but is redefined by 
windows.h), so move the order around a bit where it matters.
3. MinGW's InterlockedIncrement does not properly handle the volatile modifier, 
so remove it from the instance_count_ variable for MinGW.

There are still thing that are problematic, e.g., MinGW itself does not include 
DbgHelp.h (must be fetched from the Windows SDK), the mixed-case file names 
present problems when cross-compiling from Linux, and there is no build system 
support, but at least it makes it a lot easier to get things going.

Original issue reported on code.google.com by se...@google.com on 21 Jul 2011 at 4:08

Attachments:

GoogleCodeExporter commented 9 years ago
thank you, going to try that out! Would be great if you could further develop 
this patch so we'll have full Breakpad MinGW support sooner or later

Original comment by csemmler...@googlemail.com on 24 Jul 2011 at 1:23

GoogleCodeExporter commented 9 years ago
I forgot one point in my patch; there should also be _MSC_VER #ifdefs around 
the #pragme warning, since GCC (ironically) throws warnings on those. If that's 
done, at least the client header file compiles fine with -Wall -Werror (short 
of DbgHelp.h, which you really can't do much about).

Original comment by se...@google.com on 24 Jul 2011 at 8:08

GoogleCodeExporter commented 9 years ago
Actually, using a copy of dbghelp.h from WINE or ReactOS might help with the 
warnings.

Original comment by naesten on 23 Nov 2011 at 5:23

GoogleCodeExporter commented 9 years ago
Thanks for a great patch! 

I've got breakpad compiling with MinGW and producing some dumps, next
thing is to export symbols from client application into the processor.

Do you have any experience with this?

Original comment by pavel.su...@gmail.com on 1 Dec 2011 at 12:22

GoogleCodeExporter commented 9 years ago
Den 01:23 1. desember 2011 skrev  <google-breakpad@googlecode.com> følgende:

Sorry; I've never used the processor part at all. All I'm using
Breakpad for is getting minidumps (and I wish winedbg were better,
since it's the only thing on Linux that can handle those minidumps
:-/).

/* Steinar */

Original comment by se...@google.com on 6 Dec 2011 at 1:31

GoogleCodeExporter commented 9 years ago
Hey, you can make minidumps into human-readable stack traces with the very 
breakpad processor. Or, what type of processing you are talking about -- some 
live debugging perhaps?.. 

I'm just in the process of making a simplest possible complete solution for 
dump handling in Qt/MinGW app, and dumpsyms and processor are quite good (the 
only problem is the lack of proper debug attributes in some modules in the 
integrated application), I'll report on my experience in more detail when got 
to a stable point.

Original comment by pavel.su...@gmail.com on 6 Dec 2011 at 10:04

GoogleCodeExporter commented 9 years ago
I don't think I ever got the processor to work, but I didn't try that hard 
either. (Can it read the DWARF format etc. that MinGW uses? It's not the same 
as the Visual Studio debug formats.)

Ideally, what I'd like is to be able to open up gdb and debug my app in WINE. 
But I am probably quite marginal in how I do Windows software :-) A second best 
would be able to read the backtrace, look at the stack and dump the registers 
-- unfortunately winedbg is so old it doesn't even understand the XMM registers.

Original comment by se...@google.com on 6 Dec 2011 at 10:34

GoogleCodeExporter commented 9 years ago
Has there been any progress on MinGW support lately?

Original comment by johan.t...@gmail.com on 17 Jan 2013 at 9:16

GoogleCodeExporter commented 9 years ago
Hi, I would like to know if someone is still working on MinGW support.

Best regards.

Original comment by luischiv...@gmail.com on 3 Sep 2013 at 12:55

GoogleCodeExporter commented 9 years ago
I am not.

Original comment by se...@google.com on 3 Sep 2013 at 1:40

GoogleCodeExporter commented 9 years ago
> I don't think I ever got the processor to work, but I didn't try that hard 
either.
> (Can it read the DWARF format etc. that MinGW uses? It's not the same as the 
Visual
> Studio debug formats.)

I wrote a patch teaching dump_syms to read the DWARF debug sections in PE/COFF 
used by MinGW and Cygwin gcc.

https://breakpad.appspot.com/1144002/

You then run into the issue that gcc produced binaries do not have a CodeView 
record for the windows minidump writer to capture, so the processor can't 
locate the corresponding symbol file.

Patch to binutils to add that at 
https://sourceware.org/ml/binutils/2014-01/msg00296.html

Original comment by b152fee4...@gmail.com on 18 Feb 2014 at 1:43

GoogleCodeExporter commented 9 years ago
So if i'm not wrong binutils seem to have accepted your patch? May i ask what 
the status is on the review for the breakpad part? It would be really nice to 
finally have support for mingw generated dumps :) Thanks alot so far to 
everyone for the amazing work on this library.

Best regards.

Original comment by adrian.j...@googlemail.com on 19 Jun 2014 at 9:15