Decide if factoring symbol stuff makes sense for profile-symbolicate and



6 years ago
8 months ago


(Reporter: dhylands, Unassigned)


Firefox Tracking Flags

(Not tracked)




6 years ago
When we fix 820097 it may make sense to create a common module which can be used by utilities such as and

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; 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
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.