We could also teach the assembler to do that when it sees TOPFRAME annotations.

I looked into this a bit. It wouldn't be straightforward because, for example, the sigtramp implementations are marked TOPFRAME, but it's important for those functions to save registers following the platform ABI. So telling the assembler/linker to insert MOV $0, FP or something similar for TOPFRAME functions wouldn't be right.

Other things I can think of:

• Just manually fix up mstart implementations to clear the frame pointer on platforms where we want to do unwinding? Assuming it's worth trying to introduce frame-pointer unwinding for the heap profiler, for example, this is the situation where it wouldn't work today. Could do the same for other TOPFRAME functions
• Build a table of address ranges for TOPFRAME functions, have frame-pointer unwinders check for them to know when to stop. This might be more robust but would also hurt performance.
• Don't try frame-pointer unwinding in this situation

There should be only a small number of TOPFRAME functions. Fixing them up manually sounds reasonable. If there are ones that are tricky or not possible to fix (like sigtramp mentioned above), we can think about what to do with them.

Build a table of address ranges for TOPFRAME functions, have frame-pointer unwinders check for them to know when to stop. This might be more robust but would also hurt performance.

I assume we need to keep a table of stack addresses (not PCs)? Maybe doable but it is probably hard to maintain that table, and as you mentioned, also hurt performance. Maybe we can check for whether the new FP falls out of the stack boundary and stop if so? But we also want to handle stack transitions in FP unwinding? Then maybe we'd need to check both g0 and curg's stack bounds.

Maybe we can check for whether the new FP falls out of the stack boundary and stop if so? But we also want to handle stack transitions in FP unwinding? Then maybe we'd need to check both g0 and curg's stack bounds.

Yeah, that might be more trouble than it's worth. IMO, if there's only Go code in the call chain, frame pointer unwinding should ideally work with no extra guardrails. Since we fully control the compiler and runtime, we can properly fix cases where it doesn't work.

There should be only a small number of TOPFRAME functions. Fixing them up manually sounds reasonable. If there are ones that are tricky or not possible to fix (like sigtramp mentioned above), we can think about what to do with them.

Agreed, seems reasonable to me 👍

Change https://go.dev/cl/540476 mentions this issue: runtime: use frame pointer unwinding for the heap profiler

But we also want to handle stack transitions in FP unwinding?

I have some experience now trying to do this for heap profiling. In the case of mcall I don't think this will be possible all of the time. Specifically, when a goroutine uses mcall to call back into the scheduler (e.g. for blocking), the M will eventually drop the goroutine and wait for more runnable work. Once that happens, the goroutine which initiated the mcall can later be rescheduled on another M. That will invalidate the frame pointer saved by mcall.

I saw this problem trying to do FP unwinding for heap profiling. For example, we might allocate a new M during resetspinning, and FP unwinding from that point to sample that allocation can reach an mcall frame, with a frame pointer that's now invalid. This results in a crash.

I think we should probably have mcall also clear the frame pointer to indicate that unwinding shouldn't cross that stack boundary, since in general it's not safe. Does that make sense?

I agree in general it may not always be safe or sensible to unwind through stack transition. I think it may be reasonable to unwind through a user-to-system stack transition (like calling systemstack or asmcgocall) but not the other way around (like the scheduler executing some user goroutine).

I don't know the specifics about resetspinning. Is this mcall special? Could it have a valid frame pointer?

Is there a case we do want to traceback through an mcall? If not, we probably clear the frame pointer in mcall.

I don't know the specifics about resetspinning. Is this mcall special? Could it have a valid frame pointer?

Sorry, I left out some detail. resetspinning is something called during schedule (here) that can lead to a memory allocation, and recording that allocation for the heap profile using FP unwinding can crash. Mainly I meant it as an example where we might want to record a call stack during an mcall-ed function, where FP unwinding might not be safe any more.

The general pattern is that a goroutine calls mcall(somefunc), which will run somefunc on the g0 stack. somefunc arranges somehow for the goroutine to run later, then calls into the scheduler. gosched_m, for example, is called through mcall when a goroutine voluntarily yields to the scheduler, and it arranges for the goroutine to run by putting it on the global run queue. Once somefunc gives up the goroutine, the goroutine can be rescheduled later and invalidate the frame pointer saved by mcall.

Is there a case we do want to traceback through an mcall? If not, we probably clear the frame pointer in mcall.

No, I don't think so. We have some execution tracing events recorded during mcall-ed functions. In the gosched_m example we record the call stack of the goroutine at the point where it yielded for the traceGoSched event. But, we don't need to go through mcall, since we'll also have the goroutine's frame pointer saved in the gp.sched.bp field and we can start unwinding from there. In any such case, the event is always recorded before making the goroutine runnable again, so we know the unwinding will still work.