Closed Bug 548113 Opened 10 years ago Closed 10 years ago

Sync to Breakpad revision 554 to pick up DWARF CFI + ARM work

Categories

(Toolkit :: Crash Reporting, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.3a4
Tracking Status
status1.9.2 --- .4-fixed

People

(Reporter: jimb, Assigned: ted)

References

Details

(Whiteboard: [fixed-lorentz])

Attachments

(2 files)

We should replace the Breakpad sources currently in Mozilla Central with the current upstream sources, and apply our patches for DWARF CFI/.eh_frame support and ARM and x86_64 unwinding.

At the moment, we have a number of substantial patches to Breakpad awaiting review from Google.  These include support for DWARF CFI (needed to enable the -fomit-frame-pointer optimization on Linux and Mac), and unwinding on ARM; unwinding on x86_64 should be ready soon.  We would like to get these into the tree early to shake out any bugs, without waiting for them to land upstream.

Also, the current upstream Breakpad sources include DWARF support; upgrading our copy to the current sources will allow us to stop using STABS in our nightly and release build process.

The procedure should be as follows:

1) Establish a public Mercurial repository holding the patch queue we have applied to the upstream Breakpad sources, yielding the sources we have put in tree. This will allow us to rebase as needed.

2) Update the Breakpad sources in Mozilla Central.

3) Install a freshly built Breakpad dump processor on Soccoro.

4) Switch nightly/etc. builds from STABS to DWARF; the new processor should just handle this transparently.

5) Enable the -fomit-frame-pointer optimization.
Depends on: 517832, 464750
Stealing this.
Assignee: jim → ted.mielczarek
Summary: Breakpad CFI patches should be in Mozilla Central now for testing → Sync to Breakpad revision 554 to pick up DWARF CFI + ARM work
Ick. The updated DWARF reader code doesn't compile in our tree, because it uses dynamic_cast and we compile with -fno-rtti.

Jim: is it possible to fix the code in dwarf2reader.cc to not use dynamic_cast?
Almost certainly, if one is willing to be ugly. :)  Let me take a look.
Here's the local Makefile changes necessary to build with Breakpad SVN r554. The actual Breakpad changes are many and can be seen here:
http://hg.mozilla.org/try/rev/d2fec8ccdc5e

but they've all been reviewed upstream.

I've also pushed this to the try server just to check that it doesn't break anything on Mac or Windows.
Attachment #433403 - Flags: review?(jim)
Comment on attachment 433403 [details] [diff] [review]
A few Makfile bits

Looks good to me.

Could we change the comment in src/common/dwarf/Makefile.in to the below?

# The Google C++ Style Guide permits the use of RTTI/dynamic_cast in
# limited situations; one such arises in the DWARF CFI parser.
Attachment #433403 - Flags: review?(jim) → review+
Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/df8d581bf479
http://hg.mozilla.org/mozilla-central/rev/758ed71fe5fc

I'll file followup bugs on updating the production processor code, switching to DWARF symbols on Linux builds, and enabling Breakpad by default on Linux x86-64/ARM.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: 554021
Blocks: 554024
(In reply to comment #7)
> I'll file followup bugs on updating the production processor code

bug 554019

> switching to DWARF symbols on Linux builds

bug 554024

> and enabling Breakpad by default on Linux x86-64/ARM.

bug 554021
Flags: in-testsuite-
Target Milestone: --- → mozilla1.9.3a4
Version: unspecified → Trunk
Flags: in-testsuite-
(In reply to comment #7)
> Pushed to m-c:

Awesome!
Depends on: 554854
I may have to back this out until bug 554854 gets sorted out, since that's preventing us from getting debug symbols at all on Linux builds right now.
I pushed a workaround, we'll see if it fixes that bustage:
http://hg.mozilla.org/mozilla-central/rev/33d05f60932b
Comment on attachment 433923 [details] [diff] [review]
(Cv1-CC) Copy (the useful part of) it to comm-central
[Checkin: Comment 17&18]

reviewing, but requesting Mark's feedback as an rs+ as I'm not sure if we want special lorentz tracking for stuff which lands there. (I'm not completely certain on integration plan with that branch, or if it will/does affect TB)
Attachment #433923 - Flags: review?(bugspam.Callek)
Attachment #433923 - Flags: review+
Attachment #433923 - Flags: feedback?(bugzilla)
Blocks: 555674
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed
Attachment #433923 - Flags: feedback?(bugzilla) → feedback+
Comment on attachment 433923 [details] [diff] [review]
(Cv1-CC) Copy (the useful part of) it to comm-central
[Checkin: Comment 17&18]

http://hg.mozilla.org/comm-central/rev/6b7f5500b3a5
Attachment #433923 - Attachment description: (Cv1-CC) Copy (the useful part of) it to comm-central → (Cv1-CC) Copy (the useful part of) it to comm-central [Checkin: Comment 17]
Comment on attachment 433923 [details] [diff] [review]
(Cv1-CC) Copy (the useful part of) it to comm-central
[Checkin: Comment 17&18]

+
http://hg.mozilla.org/comm-central/rev/a2acbb7ab6e4
(Dv1-CC) Remove obsolete MOZILLA_1_9_2_BRANCH check
Attachment #433923 - Attachment description: (Cv1-CC) Copy (the useful part of) it to comm-central [Checkin: Comment 17] → (Cv1-CC) Copy (the useful part of) it to comm-central [Checkin: Comment 17&18]
You need to log in before you can comment on or make changes to this bug.