[COD-2349] feat(callgrind): track subprocesses across fork and exec

[GuillaumeLagrange]

Track subprocesses spawned by a benchmark so they can be measured and
attributed back to the benchmark that spawned them, across both fork and
exec.

Two independent pieces, one per commit:

1. Forward instrumentation state across a traced exec. A process spawned
via exec under --trace-children=yes gets a fresh valgrind whose
instrumentation state resets to --instr-atstart, so a benchmark reached
through an exec chain (e.g. cargo run) was measured from the wrong point. A
plain fork inherits the state with the address space, but an exec does not.
This adds a VG_(needs_child_exec_args) tool need: the core asks the tool for
extra valgrind arguments while building the child's argv at exec time and
appends them after VG_(args_for_valgrind) (later options win). Callgrind uses
it to forward --instr-atstart=<current state>. Wired into the exec argv
construction on Linux (generic), Darwin, and Solaris.

2. Record spawned subprocesses per dump part. When a benchmark spawns a
subprocess, the profile had no way to attribute that subprocess to the exact
benchmark (dump part) that spawned it. On fork the parent now records the new
child pid against the part currently being measured, and each part's header
lists the children spawned during it as desc: Spawned pid: lines (a desc
field so kcachegrind and callgrind_annotate ignore it). A fork child restarts
its part counter at 1 and drops the inherited edges so it only reports children
it spawns itself, and zeroes cost so work before the fork stays attributed to
the parent.

To carry the child pid to the fork hook, VG_(atfork)'s parent callback now
takes the pid of the just-created child; the pre/child callbacks are unchanged.
All fork/clone sites (Linux, FreeBSD, Solaris, generic) pass it through. The
child hook also re-stamps the in-flight fork syscall's start time from the
child's clocks, since the thread CPU clock restarts in the child and the exit
delta would otherwise underflow.

The spawn edge is recorded parent→child rather than child→parent: at fork time
the parent already knows both the child pid and its own live part, so no spawn
identity needs to cross the exec boundary — only the instrumentation state
does. This is a change from the earlier squashed design that emitted
desc: Spawned by: <pid>:<part> from the child; see the COD-2349 discussion for
the full rationale.

Stacked on top of #24 (COD-3196, per-thread dump support), which this builds
on for the retired-thread handling in the fork/exec paths.

Behavior verified with fork/exec integration tests in the valgrind-helpers repo
(subprocess measured and recorded across fork, across a traced exec, through a
deep fork tree, and one child recorded per part across a two-part run).

Closes COD-2349

[greptile-apps]

Greptile Summary

This PR tracks benchmark subprocesses across fork and exec. The main changes are:

• Forwards Callgrind instrumentation state across traced execs.
• Records spawned child PIDs against the active dump part.
• Preserves and flushes retired-thread costs in per-thread dumps.
• Passes child PIDs through parent fork callbacks on supported platforms.
• Discards spawn records after their associated part is written.

Confidence Score: 5/5

This looks safe to merge.

• The updated cleanup removes records only for the part that has finished dumping.
• Empty-cost parts still write a section before their spawn records are discarded.
• Output-open failures stop the path before cleanup, preserving records that were not emitted.

Important Files Changed

Filename	Overview
callgrind/dump.c	Writes subprocess metadata per dump part and removes emitted records to prevent unbounded retention.
callgrind/main.c	Tracks forked children, resets child state, and forwards instrumentation state across execs.
callgrind/threads.c	Retains exited-thread data until it can be included in per-thread dumps.
coregrind/m_libcproc.c	Extends parent fork callbacks with the newly created child PID.

_{Reviews (5): Last reviewed commit: "feat(callgrind): inherit instrumentation..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 60 skipped benchmarks¹

---

_{Comparing cod-2349-support-subprocesses-in-valgrind (4d05dec) with cod-3196-fix-valgrind-separate-threadsyes-behavior-to-represent-os (febc434)²}

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. ↩

2. No successful run was found on cod-3196-fix-valgrind-separate-threadsyes-behavior-to-represent-os (448b7d0) during the generation of this report, so 481509e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[art049]

As discussed it would be simpler to have a new inherit mode that would resolve a file owned by the parent process declaring if instrumentation is enabled or not.
It will make the overall change in the logic of the codebase more isolated and easier to maintain.

[codspeed-hq]

Unable to generate the flame graphs

The performance report has correctly been generated, but there was an internal error while generating the flame graphs for this run. We're working on fixing the issue. Feel free to contact us on Discord or at support@codspeed.io if the issue persists.