Closed Bug 895162 Opened 11 years ago Closed 11 years ago

Investigate how dwarf info fixes stackwalks when PC is in prologue/epilogue on arm

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: huseby, Assigned: huseby)

References

Details

(Keywords: perf, Whiteboard: c=profiling)

Attachments

(4 files)

It is assumed that the dwarf info can help fix stack walks when the profile sig handler fires and the PC is in the prologue/epilogue of a function.  When that occurs, the arm exception handling index/microcode doesn't work because the stack frame isn't fully set up/taken down.

This bug is to track the investigation of how dwarf information helps fix this problem, and can we steal/use it to make the stack walking more robust when using the arm exception handling index data.

This is not a high priority since the having the profile sig handler fire when the PC is in an prologue/epilogue is relatively rare.  And this is just a profiler, if we lose a small percentage of samples due to bogus stack walks, we'll still get plenty of useful profiling data.
Blocks: 895154
No longer blocks: 859154
Assignee: jld → dhuseby
I'll take a look at what DWARF data can give us that we may be able to use to fix the PC when the profile signal handler gets called during a function prologue/epilogue.
Attached file DWARF for the ARM Architecture.pdf (deleted) —
Attached file DWARF 3 Standard.pdf (deleted) —
Attached file Debugging using DWARF.pdf (deleted) —
I attached some useful documents on this subject.  The current state of my research is this:

1. We generate, but strip DWARF information from our binaries.
2. DWARF not only includes prologue/epilogue annotations for locations in the binary, but also explicit call frame information specifically for stack unwinding.
3. We may be able to extract the bits we need during the stripping process for use by the profiler.  Or alternatively, we could try to rework the build scripts so they don't strip out the DWARF data.
GCC supports -gsplit-dwarf which causes the compiler to put as much of the DWARF debugging information into a separate file with a .dwo extension.  This could be a shortcut towards using DWARF data in the profiler without having to deal with bigger binaries as a result.
Scratch that, -gsplit-dwarf seems to have been removed from GCC.  At least it isn't present in the toolchain we use to compile B2G.
Status: NEW → ASSIGNED
My notes are here: https://wiki.mozilla.org/User:Dhuseby#Bug_895162_Notes
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: