820101 - Decide if factoring symbol stuff makes sense for profile-symbolicate and b2g-fix-stack.py

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Dave Hylands [:dhylands]]

When we fix 820097 it may make sense to create a common module which can be used by utilities such as b2g-fix-stack.py and profile-symbolicate.py

This bug is to evaluate if that makes sense, and if so then to do the work.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Separately from bug 820097, I have yet another address-to-symbol translator that I wrote for bug 831611.  In that case I had already translated the addresses into file offsets (the perf event stream reports mmaps as they happen, so it's possible to correctly handle mappings that change during the profile), and I needed to deal with kernel symbols as well, so it made more sense to write my own.

But also: it uses load commands to map offsets back into unrelocated virtual addresses instead of assuming that offset==virtAddr, because I had samples for more than just libxul.so; and it uses the symbol table (because I already had to parse nm(1)-format text to use kallsyms) instead of addr2line, which is faster and simpler and doesn't need any of the debug_* sections, though it reports only the outermost of a stack of inlined functions.  On the other hand, I'm not yet using symbol sizes, so addresses from internal symbols in a stripped binary (with .symtab removed) will be misattributed.

So I could factor that out and convert profile-symbolicate to use it, if that's the direction we wanted to take.  In particular, we might start to care about the speed of profile-symbolicate more when bug 810526 lands.

Comment 2

[BMO Automation]

Firefox OS is not being worked on