Zero frame pointer register in Reset

[KingCol13]

Hi, I'm new to this low level stuff so sorry if I get something wrong.

I've been trying to work out how to do a frame pointer stack walk using r7 for some profiling but I've been having trouble working out when to stop the walk. It works fine until I get to <main>'s frame record, at which point the frame pointer points into the boot RAM which I don't seem to be able to read. Would it be reasonable to zero the frame pointer r7 in <Reset>?

Section 6.2.1.4 of the AAPCS32 states:

The end of the frame record chain is indicated by the address zero in the address for the previous frame.

so I think making this change would conform with that.

Environment

I've been using a Pico 2 with an embassy application to test.

The gdb commands I've been using for walking the stack are:

info registers r7
p/x *((addr + 0*4) as *u32)

and for getting return addresses:

info registers lr
p/x *((addr + 1*4) as *u32)

[adamgreig]

Thanks for reporting the issue! In principle there's no problem setting r7 to 0 in the reset routine, but I can't actually find any other startup routine doing it - including in CMSIS, in ST's examples, in some RTOSs etc. I understand generally debuggers use the debug information in the ELF to do stack tracing instead, which might be why it's not been a bigger problem.

If anyone can find an example of a startup routine that zeros r7 it would be interesting to see. We could go ahead and do it anyway but I'd like to understand why it's not more widely done.

[KingCol13]

Thanks for the reply! Sorry I had missed the discussion in #468. I checked the startup code linked in this comment and others but couldn't find any which zero r7. The only tangentially related discussion I found was this tock discussion about disabling frame pointers and a zephyr discussion on implementing frame pointer based sampling profiling, neither of these relate to startup code though.

I think you're right that most people use DWARF information for unwinding when debugging. From searching it looks like most people recommend tracing profilers with the Embedded Trace Macrocell and a (fairly expensive) trace probe for profiling.

On my probe-rs branch I have implemented frame pointer based profiling:

as well as DWARF based profiling:

the DWARF flamegraph is visibly a bit broken, and the time to take 1 sample is 100x longer for DWARF than with frame pointers. When I posted this I had assumed that DWARF unwinding was inherently much slower but after investigating more this doesn't seem to be the case (the number of registers read per frame is the same). I also assumed there was some problem with the DWARF Call Frame Information (after reading this paper) but again after investigating I think it's a problem with probe-rs's unwinder instead, as it disagrees with gdb, the frame pointer unwinding and me manually working through the CFI. The only remaining advantages of frame pointer unwinding that I can think of are:

• It could be done more easily on the device.
• It can be done without access to the flashed ELF, though this requires r7 zeroed in startup. The generated callstacks are a bit useless without the ELF though.
• It is much simpler (this might be the most important one).

If I had a robust method for getting the address range of the entry point then I could use this as a stopping condition for the frame pointer unwinding instead. In that case, maybe it would be useful to have r7 zeroed in startup available as a feature flag but it would not be as crucial for a sampling profiler as I had thought.

[jonathanpallant]

When I wrote the aarch32-rt library for Cortex-R and Cortex-A processors, I actually elected to zero every register, just to ensure a consistent state. It shouldn't technically matter, but I was happy to spend the 15 clock cycles at start-up setting them all to zero.

So I'm in favour of zero'ing r7 at a minimum, and I'm fine with doing all of them.

[wt]

I think zeroing seems like a good idea. Initialized registers seems like a reasonable thing.