431838 - Breakpad for Linux (ARM)

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, enhancement, P3)

Description

[Christian Sejersen]

Comment 1

[(not currently active) Ted Mielczarek]

This is going to need an upstream Breakpad issue, and someone who knows ARM pretty well to do the port. I can act as a Breakpad liaison if you have an ARM expert that just needs pointers in the Breakpad source.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

What's all needed for the port?
src/processor/stackwalker_arm.c
src/processor/stackwalker_arm.h
and additions to:
src/processor/minidump.cc
src/client/linux/handler/minidump_generator.cc 
?

Comment 3

[(not currently active) Ted Mielczarek]

You can see my patch here for where I implemented server-side support for x86-64 (although not a complete stackwalker):
http://code.google.com/p/google-breakpad/issues/detail?id=196
You can also see where sparc support was implemented here:
http://code.google.com/p/google-breakpad/issues/detail?id=201

Finally, Brad pointed me at some MSDN docs that indicate that Windows CE is capable of writing minidumps. I'm not sure if they're the same format as the desktop type, which is what Breakpad uses, but I'd love to find that out and if possible share data structures:
http://msdn.microsoft.com/en-us/library/ms939618.aspx
http://msdn.microsoft.com/en-us/library/ms939656.aspx

Breakpad's minidump structure is designed to be compatible with Microsoft's definition, as we're using the DbgHelp APIs to write them out on Windows. As such, definitions like:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/common/minidump_cpu_x86.h

Are essentially ported from the Windows headers. If WinCE minidumps are not fundamentally different from this format, we should use their structure definitions for ARM stuff so as to keep compatibility.

Comment 4

[(not currently active) Ted Mielczarek]

(In reply to comment #3)
> Are essentially ported from the Windows headers. If WinCE minidumps are not
> fundamentally different from this format, we should use their structure
> definitions for ARM stuff so as to keep compatibility.

I looked into this a while ago, WinCE dumps are completely incompatible (although quite similar to minidumps in structure). We'll be implementing something else.

I have most of the processor (server-side) portions of this done, except for stack walking, which will require jimb's CFI work anyway.

Comment 5

[(not currently active) Ted Mielczarek]

Basic server-side support landed upstream:
http://code.google.com/p/google-breakpad/source/detail?r=454

Comment 6

[(not currently active) Ted Mielczarek]

Neal (a Googler) implemented most of the client-side work for Linux/ARM:
http://codereview.chromium.org/543125 (has yet to land)

and I finished off the few bits that were left:
http://breakpad.appspot.com/56002 (needs cleanup and review)

but I was able to generate a working minidump on an N900 with those patches. Woo!

I sent the dump to jimb, he was looking at some symbol dumping issues.

Comment 7

[Jim Blandy :jimb]

Got an ARM backtrace; more unit tests needed, but these are baby steps, at least. My post to [e-mail]:

http://groups.google.com/group/google-breakpad-dev/browse_thread/thread/13c02785ff8560f7
----
Ted, does this look close to right for that little ARM executable and
minidump you sent me?

Operating system: Linux
                  0.0.0 Linux 2.6.28-omap1 #1 PREEMPT Wed Oct 28
15:32:55 EET 2009 armv7l
CPU: arm
     0 CPUs

Crash reason:  SIGSEGV
Crash address: 0x0

Thread 0 (crashed)
 0  testcrash!crash [test.cc : 17 + 0x8]
    r13 = 0xbeb8d51c   r14 = 0x000092d0   r15 = 0x00009228
 1  testcrash!main [test.cc : 23 + 0x3]
    r13 = 0xbeb8d520   r15 = 0x000092d0
 2  libc-2.5.so + 0x14973
    r13 = 0xbeb8d590   r15 = 0x4103c974

Loaded modules:
0x00008000 - 0x00019fff  testcrash  ???  (main)
0x41000000 - 0x4101bfff  ld-2.5.so  ???
0x41028000 - 0x4113efff  libc-2.5.so  ???
0x41150000 - 0x4115afff  libgcc_s.so.1  ???
0x41320000 - 0x4138cfff  libm-2.5.so  ???
0x416e8000 - 0x417affff  libstdc++.so.6.0.9  ???

Comment 8

[Jim Blandy :jimb]

Code complete, unit tests with full code and branch coverage. Posted to Google for review:

http://breakpad.appspot.com/62002/show

Comment 9

[(not currently active) Ted Mielczarek]

Neal has merged both of our patches and is pretty close to landing:
http://breakpad.appspot.com/61001/show

Comment 10

[Jim Blandy :jimb]

The patches mentioned in comment 8 and comment 9 have all landed, so I'm closing this.

Comment 11

[(not currently active) Ted Mielczarek]

FWIW, enabling this by default on ARM is tracked in bug 554021.