Closed Bug 517832 Opened 11 years ago Closed 11 years ago

Breakpad DWARF CFI: Mac dumper should parse and emit DWARF CFI


(Toolkit :: Crash Reporting, defect)

Not set



Tracking Status
blocking2.0 --- beta2+


(Reporter: jimb, Assigned: jimb)



In Breakpad, the only code shared by the Mac and Linux dumpers is the DWARF parser.  So while bug 517826 and bug 517830 will get us closer to being able to use -fomit-frame-pointer on Mac, there is still work needed on the Mac symbol dumper.

Specifically, the dumper should use the DWARF CFI parsing API provided in 517826, and then write it out in the format described in bug 517825.  This could mean simply adapting the Mac dumper to use google_breakpad::Module, or making the entire dumper shared between Mac and Linux, but I don't know whether the Mac dumper does special things that we'd need to take into account.  (Guess it's time to learn Objective C++.)
Depends on: 464750
I'm working on this.
Assignee: nobody → jim
There are quite a few bugs in the Breakpad bug database filed against the Mac dumper, so this work is probably going to run into a number of preexisting issues.

DWARF support in dump_syms on Mac OS X crashes for 64-bit binaries

dump_syms crashes on PPC

Mac dump_syms crashes when built with gcc-4.2 at -O1, -O2, or -O3

Random crashes of dump_syms on Mac
Blocks: 548113
Jim: while you're in there, would it be much work to make the dumper compile and work on x86-64? bug 411588 covers making x86/x86-64 universal builds on OS X, and one consequence of that is that we try to compile the dumper code for x86-64 and fail.
Blocks: 554364
No longer blocks: 554364
I've got a patch queue up at the URL below that changes the Mac dumper and Linux dumper to share all their DWARF parsing and symbol file generation code.  It builds in 32-bit and 64-bit mode, and dumps either with either.

Further work:
- Plug in the CFI dumper.  Assuming Apple hasn't changed their .eh_frame or .debug_frame formats, this should just work.
- Plug in the STABS parser.  I don't really know how much Apple has changed their STABS format, but I'm expecting this to just work, too.
Got running code, 32- and 64-bit ready, x86, x86_64, and ARM, in the patch queue:

Need to plug in the STABS parser, and some other small issues.
Did you test your dumper against PPC binaries? (Doesn't have to be on a PPC system, just -arch ppc would be fine.) We're still producing i386/ppc nightly builds.
Yep, we can dump debugging info on PowerPC.
Okay, my current patch series at the usual location has working Linux
and Mac dumpers, 32- and 64-bit, x86, x86_64, PowerPC and ARM, DWARF
and STABS, sharing all but the top-level driver code.

The top-level driver code should be per-platform, because Linux and
Mac use different object file formats (ELF vs. Mach-O), and Mac OS X
has weird requirements regarding fat binaries, .dSYM bundles, and
non-canonical filename representations.  The environments aren't
similar enough.  But we're talking about around 400 lines of code for
Mac, 600 for Linux.
I've got sixteen patches in for review from Google.  There are four more to get neatened up that do the real work; I should be able to get them in by the end of Monday.
The Google patch review queue is here:
All patches posted for review from Google.  Patch queue URL as above.
nom'd because we need this for shipping 10.6 64bit builds.
blocking2.0: --- → ?
Taking, I'm going to clean up Jim's patches and get them landed.
Assignee: jim → ted.mielczarek
I've got Jim's first patch updated per review comments, just need to post it for final review:

There's just one more (large-ish) patch to get updated. I expect I'll get it finished in the next day or two.
blocking2.0: ? → beta2+
This all landed upstream:
r610 - r619

Syncing to upstream is tracked in bug 567424.
Assignee: ted.mielczarek → jim
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.