gdb/testsuite: add HIP graph-launch kernel debugging test

[spatrang]

Summary

Adds a new gdb.rocm dejagnu test, hip-graph-launch, covering debugging of
kernels dispatched through a HIP graph (hipGraphLaunch) rather than a plain
kernel<<<>>>() launch. The program captures two kernels (add_one then
times_three) from a stream into a single graph, instantiates it, and replays
it 3 times; each replay computes out = (out + 1) * 3 (0 -> 3 -> 12 -> 39).

The test exercises the graph-specific debugger behavior:

• pending breakpoints in graph-launched kernels resolve and hit,
• both graph nodes stop in order on every replay (dispatch numbering / re-dispatch),
• correct per-replay data is observed at each node,
• symbol breakpoint + backtrace + kernel-argument inspection,
• single-stepping inside a graph-launched kernel mutates device memory,
• info dispatches reports the active dispatch and associates it with the kernel.

Test plan

Validated 22/22 assertions under both GCC and LLVM host compilers on gfx942
(MI300X), against:

• locally built ROCgdb (gdb 18.0.50), and
• nightly ROCm 7.14 rocgdb (gdb 16.3).

JIRA

AIROCGDB-580

[spatrang]

Rebased onto latest amd-staging to pick up the record-full.c build fix and re-trigger CI.

[lancesix]

Just minor comments for now, will get a deeper review at a later time.

[spatrang]

Addressed review comments :

• Use the shared CHECK macro from rocm-test-utils.h instead of a local copy.
• num_elems is now constexpr.
• Keep the replay count in sync: the .exp passes -DNUM_REPLAYS=$num_replays and the source guards the define with #ifndef (per the nonstop-mode.exp pattern).

Also rebased onto latest amd-staging.

[aktemur]

Assigning to myself to reduce the load on @lancesix.
@lancesix, feel free to assign it back to yourself.

[aktemur]

It's not a hard requirement, but the code style prefers to declare variables at the first time of definition. E.g. Decls above can be moved down, like so:

hipStream_t stream;
CHECK (hipStreamCreate (&stream));
...
hipGraph_t graph;
CHECK (hipStreamEndCapture (stream, &graph));

hipGraphExec_t graph_exec;
CHECK (hipGraphInstantiate (&graph_exec, graph, nullptr, nullptr, 0))
...

[aktemur]

Nit: I think this comment can be removed. It's rather repeating the code.

[aktemur]

It's mostly a personal taste: The proc continue_to_kernel is a wrapper around one gdb_test only. We can rather inline it and remove the proc. What we are testing would become clearer.

[aktemur]

If we want to make this shorter, this would also be ok, without losing quality of the test:
Breakpoint .* $kernel .*$::srcfile:$line.*

[aktemur]

clean_restart $::testfile

[aktemur]

Can we use $inferior_exited_re here?

[aktemur]

clearn_restart $::testfile

[aktemur]

Nit: The shorter variant I gave above may be used.

[aktemur]

We can print and check the value of out[0], too. The value can be passed as an argument to the proc.

[aktemur]

I'm not sure what testing value we gain by these 3 tests. The first one tested being able to hit the breakpoint inside graph-launched kernels, that's understood. But the other 3 seem like they test debug info and basic debug functionality, for which there already exist tests. I don't see why it should matter to do these for graph-launched kernels. I'd be in favor of removing them for making this test file simpler and less expensive (such tests accumulate and the overall test time may increase to unpleasant levels over time).