Open GoogleCodeExporter opened 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
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
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
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
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
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
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
Has there been any progress on MinGW support lately?
Original comment by johan.t...@gmail.com
on 17 Jan 2013 at 9:16
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
I am not.
Original comment by se...@google.com
on 3 Sep 2013 at 1:40
> 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
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
Original issue reported on code.google.com by
se...@google.com
on 21 Jul 2011 at 4:08Attachments: