Build b2g Nightly to support profiling with native stacks

RESOLVED WONTFIX

Status

()

Core
Gecko Profiler
RESOLVED WONTFIX
5 years ago
a year ago

People

(Reporter: BenWa, Assigned: jld)

Tracking

(Blocks: 1 bug)

Trunk
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(b2g18?)

Details

(Whiteboard: [leave open])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
+++ This bug was initially created as a clone of Bug #863264 +++

B2G nightlies don't support Breakpad unwinding.  We need to
enable that. We need to do something similar to bug 863264.
(Reporter)

Comment 1

5 years ago
Another option is to deploy jld's custom toolchain to the build machines and use it for enable-profiling nightly builds.

How feasible is that?
Flags: needinfo?(jld)
(Reporter)

Updated

5 years ago
Blocks: 758697
(Assignee)

Comment 2

5 years ago
Do we want this for profiling or for crash reporting?  Are we using Breakpad unwinding on B2G, or should this bug be retitled?  Note that my change to NS_StackWalk to work with my altered toolchain isn't landed yet (nor are any of the pieces for perf(1) profiling, which also depends on the unlandable toolchain changes); also, the compiler flags would have to be set manually.
Flags: needinfo?(jld) → needinfo?(bgirard)
AFAIK this is for profiling, at least.  Whether it's for crash reporting too,
I don't know.
This isn't something we need for crash reporting. I don't know if Breakpad will use frame pointers properly with -fno-omit-framepointer on arm given the fact that we build everything for thumb.

Jed: we do have a Breakpad-powered unwinder in the profiler now, but it's not on by default.
(Assignee)

Comment 5

5 years ago
As mentioned on bug 863264, as far as I can tell -fno-omit-frame-pointer on Thumb isn't helpful: it sets r7 to a value that isn't at a constant offset from the previous frame pointer and the saved LR, so it still requires interpreting PC-indexed unwinding information.  The same thing could be accomplished with -fomit-frame-pointer using SP.

(That's Thumb on arm-linux-androideabi.  iOS does things differently: http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv6FunctionCallingConventions.html but that doesn't help us.)
(Assignee)

Comment 6

5 years ago
I think I want some performance numbers on FramePointerStackWalk vs. breakpad with -mthumb2-fake-apcs-frame vs. breakpad with just -fasynchronous-unwind-tables.

(I'm also slightly curious about a hypothetical allocation-free EHABI unwinder that could be async-signal-safe without stack copying — which I think is how breakpad works currently? — but I'd have to write it first.)

For reference, I already have numbers for the kernel-based profiler with -mthumb2-fake-apcs-frame: 3% of an unagi at 2.5 kHz, rising to 7% with 100 added stack frames.
(Assignee)

Comment 7

5 years ago
However: 4182c5c0b, the change that adds breakpad, hasn't been uplifted to b2g18.  This is a problem.
(Reporter)

Comment 8

5 years ago
Sorry for the confusion. For this bug we have two options (1) Compile with the info breakpad requires to unwind with b2g (CFI/EXIDX) or (2) Use your unwind method by compiling with a custom toolchain.

I think right now our default is to proceed with (1) but I wanted to know how much work (2) would be if it's feasible at all say we install your custom toolchain and specify your custom toolchain in nightly mozconfigs when producing the nightly builds
Flags: needinfo?(bgirard)
(Assignee)

Comment 9

5 years ago
The breakpad on m-c understands only CFI.  I managed to get the .debug_frame sections for gonk and gecko onto my hamachi, and the result is that breakpad uses too much memory for Homescreen to start without crashing.

I'm told there's ARM EHABI support for the breakpad unwinder in an uncommitted state; I don't know whether or not we'd expect it to have substantially less memory usage.

Probably the fastest way forward is to finish bug 810526, get the altered toolchain onto the official build hosts (how?), and adjust mozconfigs accordingly.  That gives native stacks to the tools everyone is used to from other Geckos.

Bug 831611 needs some more thought and cleanup before parts of it start being landed.
(Assignee)

Updated

5 years ago
URL: 810526
(Assignee)

Updated

5 years ago
URL: 810526
Depends on: 810526
(Assignee)

Comment 10

5 years ago
Created attachment 746163 [details]
The patches from my experiment in comment #9

Some of this is outright uncommittable as-is (adding very b2g-specific code to what should be generic), but it worked enough for my test.

Also, "export MOZ_BREAKPAD=1" in .userconfig.  The profile.sh line is set to native instead of combined because I wanted to see what the native tracer was doing (before I got it working) without the pseudostacks in the way.
Attachment #746163 - Flags: review-
(Reporter)

Comment 11

5 years ago
(In reply to Jed Davis [:jld] from comment #9)
> Probably the fastest way forward is to finish bug 810526, get the altered
> toolchain onto the official build hosts (how?)

We can put a request with releng with a package toolchain if we decide to do that. Shall we wait for the results on android before attempting to cut b2g nightly off the custom toolchain?
(Assignee)

Updated

5 years ago
Assignee: nobody → jld
(Assignee)

Updated

5 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(Assignee)

Updated

5 years ago
Summary: Build b2g Nightly to support Breakpad Unwinding → Build b2g Nightly to support profiling with native stacks
(Assignee)

Updated

5 years ago
Whiteboard: [leave open] → c= [leave open]
(Assignee)

Comment 12

5 years ago
I assume we want this bug to apply to b2g18 builds as well as m-c?
tracking-b2g18: --- → ?
(Reporter)

Comment 13

5 years ago
(In reply to Jed Davis [:jld] from comment #12)
> I assume we want this bug to apply to b2g18 builds as well as m-c?

I was under the impression that the b2g18 landing were fairly selective and this bug may be invasive (changing build option plus either use a custom toolchain or breakpad). But I'd be happy to be wrong on this one.

At the very least we could make a profiling nightly fork.

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 14

5 years ago
(In reply to Benoit Girard (:BenWa) from comment #13)
> (In reply to Jed Davis [:jld] from comment #12)
> > I assume we want this bug to apply to b2g18 builds as well as m-c?
> 
> I was under the impression that the b2g18 landing were fairly selective and
> this bug may be invasive (changing build option plus either use a custom
> toolchain or breakpad). But I'd be happy to be wrong on this one.

There shouldn't be anything here that would affect a non-profiling build of b2g, so I hope that uplift approval wouldn't be difficult.  I'm under the impression that b2g18 is going to be where a lot of the performance attention will be focused for at least the immediate future, so (if I'm right about that) it would be good to include it.

Updated

5 years ago
Keywords: perf
Whiteboard: c= [leave open] → [c=profiling] [leave open]
Blocks: 896808
(Assignee)

Comment 15

5 years ago
Current status: When bug 810526 lands, it should suffice to uncomment the "ac_add_options --enable-profiling" from gecko/b2g/config/mozconfigs/ics_armv7a_gecko/nightly, if I understand the mozconfig system correctly.
(Assignee)

Updated

5 years ago
Whiteboard: [c=profiling] [leave open] → [c=profiling, p=1, s=2013.08.23] [leave open]
(Assignee)

Updated

5 years ago
Duplicate of this bug: 886918

Updated

5 years ago
Whiteboard: [c=profiling, p=1, s=2013.08.23] [leave open] → [c=profiling, p=1, s=] [leave open]

Updated

4 years ago
Keywords: perf
Whiteboard: [c=profiling, p=1, s=] [leave open] → [leave open]
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.