I've been working on profiling tools for Firefox OS, and one of the
central problems is getting stack traces for sample-based profiling.
The old APCS frame pointer variant (where r11/fp heads a linked list
of {fp, sp, lr, pc} frames) is convenient -- it's compatible with the
Linux kernel profiler as-is, it's simple to work with in general, and
in particular it's relatively easy to inject dynamically generated
pseudo-frames into the profile.
Of course, this doesn't work on Thumb, where the full stmdb/ldmia don't
exist. But it almost works on Thumb2 -- the sp and pc can't be stored,
and the sp can't be loaded, but it's possible to save {r11, r12, r14}
(i.e., {fp, ip, lr}) along with the other saved registers, and obtain a
frame with the fp and lr fields at the same offsets as for -mapcs-frame.
This is, conveniently, enough for the Linux kernel profiler's user stack
walker. It makes it possible to lose the second-last stack frame if
sampled between a call and committing the new frame to r11 -- I assume
this is what the saved PC is for? -- but this is the same situation
that, e.g., x86 frame pointer walking is in; and this is for profiling,
so full correctness isn't an absolute requirement.
(At some point I should mention -mtpcs-frame, which as of GCC 4.4.3
emits a nontrivial number of instructions to put the entire {fp, sp,
lr, pc} in the expected places... on Thumb1, and is silently ignored on
Thumb2, and seems to have no test coverage, and seems to have bit-rotted
in more recent versions.)
I've attached a patch (against GCC 4.4.3, because that's what we're
currently using) for comment. The option probably needs a more serious
name than -mthumb2-fake-apcs-frame, and how it interacts with related
options may not be ideal. But, more importantly, I'm essentially
inventing a vendor-specific ABI here, and I don't know if that's the
kind of thing that would be accepted.
--Jed
