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

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
8 months ago

People

(Reporter: dhylands, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
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

8 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.