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

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Dave Huseby [:huseby]]

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.

Comment 1

[Dave Huseby [:huseby]]

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.

Comment 2

[Dave Huseby [:huseby]]

Attachment: Procedure Call Standard for the ARM Architecture.pdf

Comment 3

[Dave Huseby [:huseby]]

Attachment: DWARF for the ARM Architecture.pdf

Comment 4

[Dave Huseby [:huseby]]

Attachment: DWARF 3 Standard.pdf

Comment 5

[Dave Huseby [:huseby]]

Attachment: Debugging using DWARF.pdf

Comment 6

[Dave Huseby [:huseby]]

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.

Comment 7

[Dave Huseby [:huseby]]

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.

Comment 8

[Dave Huseby [:huseby]]

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.

Comment 9

[Dave Huseby [:huseby]]

My notes are here: https://wiki.mozilla.org/User:Dhuseby#Bug_895162_Notes