[GH-ISSUE #6844] [Bug] Modern AMDGPU note triples bypass declared target conflict detection #4185

New issue

Closed

opened 2026-10-31 00:47:31 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:47:31 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6844

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

The production GpuCodeObjectsService and GpuCodeObjectsProvider do not compare an AMDGPU note target using LLVM's modern amdgpu9.00 triple with its HIP bundle target. A bundle declaring gfx1100 and a note declaring amdgpu9.00-amd-amdhsa--gfx900 return target_consistency: "unknown", inspection: "complete", complete report payload coverage, and no conflict limitation. The same synthetic declaration with the legacy amdgcn note spelling correctly returns a conflict and partial coverage. Even the matching modern-note case returns unknown instead of consistent.

Observed with inert synthetic ELF/MessagePack and HIP bundle fixtures through the shared production service. No GPU, target execution, or model runtime was used.

Reproduction

Run from the source checkout with its locked dependencies. This self-contained probe uses the repository's source-built fixture factories; no external binary is needed. The integrated four-case probe ran twice before this draft was written, and both runs produced the results below.

node --import tsx --input-type=module <<'JS'
import { mkdtemp, writeFile, rm } from 'node:fs/promises';
import { tmpdir } from 'node:os';
import { join } from 'node:path';
import { GpuCodeObjectsProvider } from './src/gpu/GpuCodeObjectsProvider.ts';
import { GpuCodeObjectsService } from './src/application/gpu/GpuCodeObjectsService.ts';
import { amdFixture, hipFixture } from './tests/fixtures/gpu/codeObjects.ts';
const dir = await mkdtemp(join(tmpdir(), 'rea-example-'));
const path = join(dir, 'input.bin');
try {
  for (const arch of ['amdgcn', 'amdgpu9.00']) {
    for (const outer of ['gfx900', 'gfx1100']) {
      const target = `${arch}-amd-amdhsa--gfx900`;
      const triple = outer === 'gfx900' ? 'amdgpu9.00' : 'amdgpu11.00';
      await writeFile(path, hipFixture(
        amdFixture(false, undefined, target),
        `hipv4-${triple}-amd-amdhsa--${outer}`,
      ));
      const service = new GpuCodeObjectsService(new GpuCodeObjectsProvider());
      try {
        const result = await service.inspect({ path, analysis: 'kernels', detail: 'complete' });
        if (!result.ok) throw result.error;
        const report = result.value.normalized_result;
        const row = report.objects.find(o => o.kind === 'amdgpu');
        console.log(JSON.stringify({
          note: target, outer, consistency: row.target_consistency,
          inspection: row.inspection, payloads: report.coverage.payloads,
          kernels: report.kernels.length, limitations: row.limitations,
        }));
      } finally { await service.close(); }
    }
  }
} finally { await rm(dir, { recursive: true, force: true }); }
JS

The displayed command is a portable transcription of the executed probe: fixture contents, production calls, and selected result fields are the same; temporary-path creation and cleanup replace the audit workspace path.

Expected behavior

Recognized modern AMDGPU triple spellings should preserve the same target comparison as the equivalent legacy spelling. A matching gfx900 declaration should be consistent; distinct declared base processors should retain both raw values, report a conflict, annotate surviving kernels, and mark object/report/target coverage partial. This is the documented target comparison contract. LLVM's released target-triple documentation defines amdgpu9.00 for gfx900, and its metadata target grammar includes the target triple in amdhsa.target.

Impact and scope

Bounded evidence correctness defect: static inspection loses a decidable agreement/conflict and fails to downgrade coverage for contradictory declared processors. Both original target strings and the kernel declaration survive, so callers can manually compare the retained raw targets. The four synthetic cases establish the shared service behavior, not prevalence in real application artifacts. NOT_ENOUGH_INFO: no real compiler-produced HIP application or GPU runtime was tested.

REA version

Package version 6.7.0, source revision 169512a35bb015ff209168fb8bc1c9b31a2c678b (main; latest published package supplied by the parent audit).

Runtime and platform

Measured Node.js v26.12.1; Linux 7.2.8-9-omarchy; x86_64. The fixture factories encode declarations in process; no CUDA/ROCm provider or compiler is involved.

Target and artifact context

Synthetic Clang HIP bundle containing one AMDGPU ELF with a MessagePack metadata note and one kernel declaration. The mismatch is deliberate static input; it is not claimed to be loadable or executable on a GPU. The modern note target itself follows LLVM's documented target grammar.

Interface

Other

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Expected source: the target comparison contract and released LLVM grammar linked above.
Failure source: the production service's observed output below, contrasting modern and legacy note spellings.
Evidence provenance: observed, from synthetic fixtures; applicability of modern triple spelling is independently grounded in the released LLVM source documentation.
Local verification: reproduced.
Reproduction completeness: complete for the static shared-service contract; real producer/runtime compatibility is not claimed.

{"note":"amdgcn-amd-amdhsa--gfx900","outer":"gfx900","consistency":"consistent","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]}
{"note":"amdgcn-amd-amdhsa--gfx900","outer":"gfx1100","consistency":"conflict","inspection":"partial","payloads":"partial","kernels":1,"limitations":["Conflicting target declarations: inventory gfx1100; payload amdgcn-amd-amdhsa--gfx900. Target agreement is not established."]}
{"note":"amdgpu9.00-amd-amdhsa--gfx900","outer":"gfx900","consistency":"unknown","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]}
{"note":"amdgpu9.00-amd-amdhsa--gfx900","outer":"gfx1100","consistency":"unknown","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]}

Typed outcome or recovery expected

A successful static report retaining both declarations and the surviving kernel, with target_consistency: "conflict" and partial coverage for the mismatch. Restoration should also preserve the matching legacy control and establish consistency for its modern equivalent.

Analysis or suspected cause

Source-derived explanation: note target parsing accepts modern triples for bundles but only amdgcn for notes. The note owner therefore yields a null comparison key, and target comparison leaves the state unknown without producing a limitation or partial coverage.

Additional context

Open-issue title and body searches found no matching modern-note report in the audit's initial inventory. Related but distinct: #6806 concerns absent AMDGPU V3 note targets and ELF-flag discovery; #6823 concerns CUBIN register conflicts. Closed #6483 covered an explicit environment component in legacy amdgcn notes; this case changes the note architecture component to the current amdgpu9.00 spelling. Closed #6719 covered recognizing that spelling in the outer HIP bundle, where kernels were lost. Here bundle recognition succeeds and the kernel survives, but the independently declared modern note target is not compared. No source files were changed.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: The observed shared-service report misses a declared base-processor conflict and retains complete payload coverage on this bounded static input; matching modern declarations also lose decidable consistency.
Workaround status: available
Workaround basis: Both raw declarations remain in the complete report, and the observed output shows callers can compare target and payload_target manually without changing or executing the artifact.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6844 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Native analysis or decompilation ## Observed behavior The production `GpuCodeObjectsService` and `GpuCodeObjectsProvider` do not compare an AMDGPU note target using LLVM's modern `amdgpu9.00` triple with its HIP bundle target. A bundle declaring `gfx1100` and a note declaring `amdgpu9.00-amd-amdhsa--gfx900` return `target_consistency: "unknown"`, `inspection: "complete"`, complete report payload coverage, and no conflict limitation. The same synthetic declaration with the legacy `amdgcn` note spelling correctly returns a conflict and partial coverage. Even the matching modern-note case returns unknown instead of consistent. Observed with inert synthetic ELF/MessagePack and HIP bundle fixtures through the shared production service. No GPU, target execution, or model runtime was used. ## Reproduction Run from the source checkout with its locked dependencies. This self-contained probe uses the repository's source-built fixture factories; no external binary is needed. The integrated four-case probe ran twice before this draft was written, and both runs produced the results below. ```sh node --import tsx --input-type=module <<'JS' import { mkdtemp, writeFile, rm } from 'node:fs/promises'; import { tmpdir } from 'node:os'; import { join } from 'node:path'; import { GpuCodeObjectsProvider } from './src/gpu/GpuCodeObjectsProvider.ts'; import { GpuCodeObjectsService } from './src/application/gpu/GpuCodeObjectsService.ts'; import { amdFixture, hipFixture } from './tests/fixtures/gpu/codeObjects.ts'; const dir = await mkdtemp(join(tmpdir(), 'rea-example-')); const path = join(dir, 'input.bin'); try { for (const arch of ['amdgcn', 'amdgpu9.00']) { for (const outer of ['gfx900', 'gfx1100']) { const target = `${arch}-amd-amdhsa--gfx900`; const triple = outer === 'gfx900' ? 'amdgpu9.00' : 'amdgpu11.00'; await writeFile(path, hipFixture( amdFixture(false, undefined, target), `hipv4-${triple}-amd-amdhsa--${outer}`, )); const service = new GpuCodeObjectsService(new GpuCodeObjectsProvider()); try { const result = await service.inspect({ path, analysis: 'kernels', detail: 'complete' }); if (!result.ok) throw result.error; const report = result.value.normalized_result; const row = report.objects.find(o => o.kind === 'amdgpu'); console.log(JSON.stringify({ note: target, outer, consistency: row.target_consistency, inspection: row.inspection, payloads: report.coverage.payloads, kernels: report.kernels.length, limitations: row.limitations, })); } finally { await service.close(); } } } } finally { await rm(dir, { recursive: true, force: true }); } JS ``` The displayed command is a portable transcription of the executed probe: fixture contents, production calls, and selected result fields are the same; temporary-path creation and cleanup replace the audit workspace path. ## Expected behavior Recognized modern AMDGPU triple spellings should preserve the same target comparison as the equivalent legacy spelling. A matching `gfx900` declaration should be consistent; distinct declared base processors should retain both raw values, report a conflict, annotate surviving kernels, and mark object/report/target coverage partial. This is the documented [target comparison contract](https://github.com/morluto/rea/blob/169512a35bb015ff209168fb8bc1c9b31a2c678b/docs/gpu-code-objects.md#L23-L37). LLVM's released [target-triple documentation](https://github.com/llvm/llvm-project/blob/llvmorg-23.1.4/llvm/docs/AMDGPUUsage.rst#L195-L201) defines `amdgpu9.00` for `gfx900`, and its [metadata target grammar](https://github.com/llvm/llvm-project/blob/llvmorg-23.1.4/llvm/docs/AMDGPUUsage.rst#L5633-L5650) includes the target triple in `amdhsa.target`. ## Impact and scope Bounded evidence correctness defect: static inspection loses a decidable agreement/conflict and fails to downgrade coverage for contradictory declared processors. Both original target strings and the kernel declaration survive, so callers can manually compare the retained raw targets. The four synthetic cases establish the shared service behavior, not prevalence in real application artifacts. NOT_ENOUGH_INFO: no real compiler-produced HIP application or GPU runtime was tested. ## REA version Package version 6.7.0, source revision `169512a35bb015ff209168fb8bc1c9b31a2c678b` (main; latest published package supplied by the parent audit). ## Runtime and platform Measured Node.js v26.12.1; Linux 7.2.8-9-omarchy; x86_64. The fixture factories encode declarations in process; no CUDA/ROCm provider or compiler is involved. ## Target and artifact context Synthetic Clang HIP bundle containing one AMDGPU ELF with a MessagePack metadata note and one kernel declaration. The mismatch is deliberate static input; it is not claimed to be loadable or executable on a GPU. The modern note target itself follows LLVM's documented target grammar. ## Interface Other ## Earliest failure stage Native analysis or reconstruction ## Relevant output or evidence - Expected source: the target comparison contract and released LLVM grammar linked above. - Failure source: the production service's observed output below, contrasting modern and legacy note spellings. - Evidence provenance: observed, from synthetic fixtures; applicability of modern triple spelling is independently grounded in the released LLVM source documentation. - Local verification: reproduced. - Reproduction completeness: complete for the static shared-service contract; real producer/runtime compatibility is not claimed. ```jsonl {"note":"amdgcn-amd-amdhsa--gfx900","outer":"gfx900","consistency":"consistent","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]} {"note":"amdgcn-amd-amdhsa--gfx900","outer":"gfx1100","consistency":"conflict","inspection":"partial","payloads":"partial","kernels":1,"limitations":["Conflicting target declarations: inventory gfx1100; payload amdgcn-amd-amdhsa--gfx900. Target agreement is not established."]} {"note":"amdgpu9.00-amd-amdhsa--gfx900","outer":"gfx900","consistency":"unknown","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]} {"note":"amdgpu9.00-amd-amdhsa--gfx900","outer":"gfx1100","consistency":"unknown","inspection":"complete","payloads":"complete","kernels":1,"limitations":[]} ``` ## Typed outcome or recovery expected A successful static report retaining both declarations and the surviving kernel, with `target_consistency: "conflict"` and partial coverage for the mismatch. Restoration should also preserve the matching legacy control and establish consistency for its modern equivalent. ## Analysis or suspected cause Source-derived explanation: [note target parsing](https://github.com/morluto/rea/blob/169512a35bb015ff209168fb8bc1c9b31a2c678b/src/gpu/AmdGpuTarget.ts#L4-L28) accepts modern triples for bundles but only `amdgcn` for notes. The [note owner](https://github.com/morluto/rea/blob/169512a35bb015ff209168fb8bc1c9b31a2c678b/src/gpu/GpuElfKernels.ts#L379-L383) therefore yields a null comparison key, and [target comparison](https://github.com/morluto/rea/blob/169512a35bb015ff209168fb8bc1c9b31a2c678b/src/gpu/GpuInventory.ts#L410-L449) leaves the state unknown without producing a limitation or partial coverage. ## Additional context Open-issue title and body searches found no matching modern-note report in the audit's initial inventory. Related but distinct: #6806 concerns absent AMDGPU V3 note targets and ELF-flag discovery; #6823 concerns CUBIN register conflicts. Closed [#6483](https://github.com/morluto/rea/issues/6483) covered an explicit environment component in legacy `amdgcn` notes; this case changes the note architecture component to the current `amdgpu9.00` spelling. Closed [#6719](https://github.com/morluto/rea/issues/6719) covered recognizing that spelling in the outer HIP bundle, where kernels were lost. Here bundle recognition succeeds and the kernel survives, but the independently declared modern note target is not compared. No source files were changed. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The observed shared-service report misses a declared base-processor conflict and retains complete payload coverage on this bounded static input; matching modern declarations also lose decidable consistency. - Workaround status: available - Workaround basis: Both raw declarations remain in the complete report, and the observed output shows callers can compare `target` and `payload_target` manually without changing or executing the artifact.

bsakaguchi closed this issue

2026-10-31 00:47:31 +00:00

bsakaguchi referenced this issue

2026-10-31 01:11:58 +00:00

[PR #4185] [CLOSED] fix(verifiers): retry transient install-root cleanup on Windows (#4136) #6115