feat(callgrind): add CALLGRIND_REGISTER_DESC client request

[lvaroqui]

Add a CALLGRIND_REGISTER_DESC(desc) client request that attaches a desc: <desc> line to the header of the next dumped part, without dumping.

A client can currently only label a part through the trigger string of CALLGRIND_DUMP_STATS_AT, and every such call creates a part of its own. Here, lines are queued, written in every section of the next part (per thread under --separate-threads=yes), then cleared. This is the same lifecycle as the existing desc: Spawned pid: lines.

The first user is instrument-hooks. It declares the pid a benchmark ran in when that is not the dumping process, so a launcher's own cost can be told apart from the benchmark's:

part: 2
desc: Spawned pid: 289126
desc: Benchmark pid: 289126
desc: Trigger: Client Request: exec_harness::true_twice

Notes for review:

• Line breaks in desc are written as spaces, so a client string cannot corrupt the header.
• A fork child drops the lines its parent queued, like the spawned pids.
• Lines queued after the last dump are lost on exit or exec.
• Older valgrind builds don't know the request: they log Warning: unknown callgrind client request code and carry on.

Ships as 0codspeed8. instrument-hooks syncs callgrind.h from this repo's master, so this has to merge first.

Stacked on #44, which fixes the inline-crossfile failure on ubuntu-22.04 this change exposed: it was caused by the tool binary's layout, not by this change.

Closes COD-3722

[codspeed]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 60 skipped benchmarks¹

---

_{Comparing cod-3722-ignore-process-spawning-overhead-in-exec-harness-simulation (fa48853) with master (57010df)}

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

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds a new client request to the profiler's public API.

The PR appears safe to merge; no outstanding finding or new actionable issue was identified.

Summary

The PR adds a client request that queues description lines for the next Callgrind dump, prints them in each emitted section, and clears them after the dump or in a fork child. It also adds single-thread and separate-thread regression tests.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[REGISTER_DESC] --> B[Queue sanitized line]
  B --> C[Next dump]
  C --> D[Write line in each emitted section]
  D --> E[Clear queue]
  B --> F[Fork child]
  F --> G[Child clears inherited queue]

Loading

_{Reviews (4) · Last reviewed commit: "test(callgrind): keep register_desc_thre..."}

[not-matthias]

Looks good, just very minor comments.

[not-matthias]

nit: maybe queue_desc might fit better. i associate "register" more with registering a callback. wdyt? 🤔

other options: dump_desc, emit_desc, add_desc, etc.

[lvaroqui]

I agree, add_desc is probably the clearest name, I'll update