[not-matthias]

Make Callgrind work on Go binaries out of the box: no GODEBUG=asyncpreemptoff, no GOMAXPROCS, no cgo.

Before this, Go programs had two problems under Callgrind:

1. Crash on the first preemption signal. Go runs every signal handler on a per-thread sigaltstack. That stack is mapped above the heap-allocated goroutine stacks, so the SP-based unwind popped through the handler's call_stack_bottom. Callgrind read that as a longjmp out of the handler. The handler's real rt_sigreturn then aborted with threads.c: Assertion 'sigNum == CLG_(current_state).sig' failed. Go raises SIGURG for async preemption and GC, so this hit every non-trivial program.
2. Unusable call graphs. Goroutines share OS threads and switch stacks without call/return pairs (runtime.gogo, runtime.mcall, runtime.systemstack, runtime.morestack, vDSO and cgo calls on g0). The single SP-based shadow stack mixed them. Examples: runtime.newobject "called" runtime.main, runtime.mcall "called" main.work.func1, and there were fake '2 recursion clones everywhere.

Changes

• fix(callgrind) (all architectures): stop unwinding at the bottom of a signal handler that runs on the sigaltstack while SP is still inside that altstack.
• feat(callgrind) (amd64 only): new callgrind/gostack.c keeps one shadow call stack per goroutine, keyed by the g register (R14). Switch functions are found by name, so this only runs once a Go runtime is seen.
  • gogo and mcall swap shadow stacks. A goroutine resumed on another thread takes its stack from there.
  • Frames run on g0 for a goroutine (systemstack, morestack, vDSO, asmcgocall) stay under the caller. They are tagged so SP comparisons never pop frames of the other stack.
  • Time a goroutine is suspended is removed from its frames' inclusive cost. Recursion counts follow the running goroutine. Shadow frames move with the goroutine stack when the runtime grows or shrinks it.
  • The jump back to a function's entry after morestack no longer counts as the function calling itself.

setup_bbcc gets one UNLIKELY(CLG_(go_runtime)) branch. Non-Go programs and non-amd64 builds take none of the new paths.

Verification

Tested on amd64 only. Fixture: 4 goroutines doing fib(27) plus 20k 1 KiB allocations, which also sends itself SIGURG. It is built with plain go build (static, Go 1.26).

Build	Result
3.26.0.codspeed9 (release)	3/3 runs abort with the post_signal assertion
This branch	runs complete, worker stacks are goexit;main.work.gowrap1;main.work.func1;main.fib;main.fib'2…

• callgrind/tests regtests: the same failure set as master (bug497723, which already fails).
• The existing C, Rust and Python call-graph fixtures give the same results as master.

Known limitations

• About 30-45 call edges inside Go runtime GC code (gcMarkDone, mallocgc, semrelease1, …) still show a '2 recursion clone. The count changes with GC timing. User code stacks are not affected.
• Goroutine tracking is amd64 only. On arm64 the altstack crash fix applies, but goroutine stacks are still mixed.
• Stack switches are recognized by runtime function names. They are stable from Go 1.17 (.abi0 suffixes) and the older names are included, but a future runtime that renames these functions would need an update.
• cgo: asmcgocall is handled. Callbacks from C into Go (cgocallback) are not tracked specially.

Closes COD-4081

[codspeed]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 60 skipped benchmarks¹

---

_{Comparing cod-4081-support-go-binaries-in-valgrind-codspeed (756bb49) with master (f3f2fda)}

Footnotes

1. 60 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩