Found it. There is this code (cmd/internal/obj/x86/asm6.go):

                    // Maintain BP around call, since duffcopy/duffzero can't do it
                    // (the call jumps into the middle of the function).
                    // This makes it possible to see call sites for duffcopy/duffzero in
                    // BP-based profiling tools like Linux perf (which is the
                    // whole point of obj.Framepointer_enabled).
                    // MOVQ BP, -16(SP)
                    // LEAQ -16(SP), BP
                    ctxt.AsmBuf.Put(bpduff1)

I'm not sure why this is necessary. Leaf routines have the same issue (they could, but don't, do any BP adjustment) and we don't insert this special code for them.

Well, it's necessary for the reason the comment says. We need a BP if you want to see who's calling duffcopy/duffzero.

For leaf routines, I thought it was just functions with a zero-sized frame that didn't do BP adjustment, which is a subset of leaf functions, but not all of them. I consider not doing BP adjustment for these a bug. It's just an unfortunate consequence of our rule to avoid adding BPs to sensitive assembly functions. But for these we still could do BP adjustment in the function prologue, but we really can't do BP adjustment in duffcopy/duffzero.

Right, it's just frameless leaf functions that don't do BP adjustment.

Do we have to worry about signal handlers? They could clobber values on the wrong side of SP. Or do we always run with a sigaltstack set up?

We always run with an alternate signal stack (otherwise receiving the signal would overrun the small goroutine stack).

Ok, I'll close this then. Ugly, but probably not buggy.