Hello all, I started working some time ago on bug 810526 (SPS on B2G doesn't get useful native stacks, because we can't build with --enable-profiling; compilation of TableTicker.cpp fails) thinking at the time that it would be a small issue mostly related to a compilation or build system problem. As it turned out obtaining backtraces for native stacks on B2G was simply not working. The default code used for getting backtraces was based on libunwind and did crash as soon as the b2g application started. To make matters worse it had already been decided that the said non-working code should be removed (bug 809571) so fixing it was not really an option.
Seeing this as a dead end I tried reusing existing functionality to deploy a quick fix for the problem; unfortunately none of my approaches worked and all failed because of the same reason which was also affecting libunwind: we currently take profile samples from a signal handler and unwinding through its stack frame is non-trivial. In our case it's made worse by the fact that the said frame seems to be using the ARM non-Thumb format in a stack which is normally made of Thumb-format frames (as we're compiling everything with Thumb support). Even GDB cannot seem to unwind it properly which is quite an issue when debugging the profiler. Long story short there's no simple solution to this problem. Fortunately Benoit Girard pointed me to bug 779291 in which Julian Seward is developing a patch that enables stack unwinding in the profiler via google-breakpad (which we already use for the crash reporter AFAIK). After getting in touch with both of them I've refreshed Julian's patch and made it to work on B2G and I got some traces out of it; they're not perfect but far better than what we had before. This prompted me to think about how to proceed on this topic as the time for v1 is almost upon us and the changes needed to enable google-breakpad unwinding are significant as you can see from the patch. Having them land in the short term is unlikely IMHO and comes with added risks. What I thought could be done instead is that I could help out with all the related issues and provide an up-to-date set of patches that would be known to work well for B2G. This would allow developers in need of proper profiling support to apply them on their own without any risk of disruption for the rest of the codebase. When Julian's finished work will land it will obviously become the default but in the meantime we would have a workable solution for profiling B2G. Towards this goal I'm considering opening a new bug to gather all that is needed and making it block on all related issues, some kind of B2G-profiling meta-bug. I'd maintain the patch-set on this bug while helping out with the dependencies. Does this sound reasonable or should we take another approach? For those who might want to experiment with the code I've refreshed Julian's patch so that it applies and builds cleanly and put it here: http://pastebin.com/ecJrM1Zq You will need to apply it together with this other patch that fixes a couple of Android/B2G-related issues: http://pastebin.com/c7MGPbeu ... and then add the following line to your b2g.sh script: export MOZ_PROFILER_MODE=combined Or this if you're only interested in seeing the native calls: export MOZ_PROFILER_MODE=native After doing this just start and use the profiler as usual. I have not put the refreshed patch on the bug for now as I don't want to create confusion around it and I'd rather first find if there's agreement on my proposal and then discuss with Julian (and whoever else might be involved) about how to proceed. Gabriele _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
