[DRAFT][rocgdb] Test filter standardization

[dileepr1]

Draft / WIP — opened to exercise CI against the paired TheRock branch. Do not merge as-is: THEROCK_COMMIT_REF in the workflows points at a feature branch and must be reverted to a pinned ROCm/TheRock SHA before merge.

Summary

Adopts TheRock's test-filter standardization (RFC0010) for ROCgdb, keeping all component-specific logic in this repo. TheRock stays component-agnostic — it only invokes its generic test_runner.py.

New sibling files under gdb/testsuite/ (installed verbatim by TheRock's existing testsuite install rule to tests/rocgdb/gdb/testsuite/):

• test_categories.yaml — source of truth for the quick/standard/comprehensive/full tiers (DejaGnu .exp selection, labels, timeouts).
• test_rocgdb.py — the DejaGnu launcher with a --tier flag (honours TEST_TYPE); self-locates rocgdb + testsuite from __file__ when run by ctest from the install tree.
• gen_ctestfile.py — dev tool that regenerates CTestTestfile.cmake from the YAML.
• CTestTestfile.cmake — pre-generated + committed; one add_test() per tier; each invokes test_rocgdb.py --tier <name> via a relative path (ctest sets the working directory to the test dir).

Workflows now invoke test_runner.py with TEST_COMPONENT=rocgdb / TEST_TYPE=standard instead of a per-component script.

Pairing

Paired with TheRock branch users/dravindr/tr_rocgdb, whose net footprint is just:

• fetch_test_configurations.py: rocgdb job → test_runner.py
• test_runner.py: a single COMPONENT_OVERRIDES["rocgdb"] entry → tests/rocgdb/gdb/testsuite

THEROCK_COMMIT_REF in therock-ci-linux.yml and therock-test-packages.yml is temporarily set to users/dravindr/tr_rocgdb so this draft builds/tests against that paired state.

Flow

workflow → test_runner.py (TheRock, generic)
        → ctest -L <tier> --test-dir tests/rocgdb/gdb/testsuite
            → CTestTestfile.cmake (ROCgdb-owned)
                → ./test_rocgdb.py --tier <name> (ROCgdb-owned)
                    → reads ./test_categories.yaml → make check TESTS=...

Test plan

• TheRock CI Linux build (gfx94X-dcgpu) succeeds against tr_rocgdb
• Run Tests job exercises ctest -L standard → test_rocgdb.py --tier standard (GCC + LLVM matrix)
• Revert THEROCK_COMMIT_REF to a pinned ROCm/TheRock SHA before un-drafting

🤖 Generated with Cursor

Made with Cursor

[lumachad]

Thanks for the PR. Some preliminary comments. I think it's mostly OK, pending adjusting location of files, lists of tests and validation.

[lumachad]

Thanks for the updates. Let me go through this again.

[lumachad]

Let's wait until #117 gets merged, as that one has a large change to test_rocgdb.py. Since this one touches that same script, we should avoid needless conflict resolution cycles.

[lumachad]

#117 has been merged. I think we can rebase the changes in this PR on top of current test_rocgdb.py.

[lumachad]

@dileepr1 Thanks. Let me go through this again and see what we should put into the test categories.

[lumachad]

@dileepr1 With rocgdb testing we have both CPU and GPU tests that must be routed to the appropriate runners to make the best use of resources. Can these filters handle that?

[dileepr1]

@dileepr1 With rocgdb testing we have both CPU and GPU tests that must be routed to the appropriate runners to make the best use of resources. Can these filters handle that?

I'll make the changes for this.

[lumachad]

Hi @dileepr1, I don't think we want to push the gpu/cpu part into test_rocgdb.py. It already knows about that via --gpu-tests and --cpu-tests. What we want to support is sharding different types of tests to their required runners.

For instance, for rocgdb we currently have the cpu tests (runs only gdb.dwarf2), gpu tests (runs only gdb.rocm) and soon we will also have the corefile tests. All 3 categories need specific runners. Can we split those at a different level that is not test_rocgdb.py itself?

If so, we wouldn't even need to modify test_rocgdb.py, and we would just modify test_categories.yml to contain that information, like TheRock's test matrix/configuration.

[dileepr1]

Thanks @lumachad, that makes sense.

You're right that the cpu/gpu split already lives at a level above the launcher — it's in TheRock's fetch_test_configurations.py (the rocgdb-cpu / rocgdb-gpu components with their --tests gdb.dwarf2 / --tests gdb.rocm selection and runner assignment). Our --domain addition just duplicated that split down into test_rocgdb.py, which is the wrong layer.

So we'll revert the --domain change and keep test_rocgdb.py generic (using the existing --tests / --gpu-tests / --cpu-tests), leaving the category → runner sharding entirely at the matrix level.

For the standardization part — could you share a sample test_categories.yml in the shape you envision (how you'd express the cpu / gpu / corefile categories, their test sets, runner requirements, and any tiering)? We'll build the framework around the structure you prefer so it lines up with how you'd want TheRock's matrix/config to consume it.

[lumachad]

Hi @dileepr1. I was thinking about this. Given we have our test script (test_rocgdb.py), we can carry on from the approach you've taken of teaching the script about the tiers (quick/standard/comprehensive/full). But we could make the tiers generic and based on the yaml file, such that we could pass --tier .

The distinction here is we will have 3 categories of tests that need to be executed each in distinct runners.

• (1) GPU tests run on GPU runners
• (2) GPU corefile tests run on special GPU runners given their corefile-specific settings
• (3) CPU tests run on GPU-less runners

I think that needs to be taken care of by upper layers. Maybe the workflow or TheRock. So each tier would fire up the tier's tests for each one of the 1/2/3 runners.

We would run something like this for each tier:

• test_rocgdb.py --tier --gpu (case 1, GPU runners)
• test_rocgdb.py --tier --corefile (case 2, GPU corefile runners)
• test_rocgdb.py --tier --cpu (case 3, CPU runners).

Do you think that could work? As for the individual tests for each tier, we would be in charge of determining those. But your initial list is fine for us.

[dileepr1]

@lumachad I've updated the PR as per above, could you re-review please?

[lumachad]

@lumachad I've updated the PR as per above, could you re-review please?

I have this on my TODO, but have a few things I need to get out of the way first, sorry.