morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #6806] [Bug] AMDGPU V3 target inventory ignores the processor declared in ELF flags #4154

New issue

Closed

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

bsakaguchi commented

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

Owner

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

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 GPU service inventories a real LLVM-produced AMDGPU V3 object as target: null, even though its ELF flags identify gfx900. Unfiltered kernel analysis returns add_one, two arguments and 12 argument bytes. Target-filtered analysis skips the same object and returns no kernels. An otherwise equivalent V4 producer control reports its target and returns the kernel when selected.

This was reproduced through GpuCodeObjectsService and the production provider, without mocking the parser or filesystem. CLI/MCP transport was not exercised.

Reproduction

With LLVM 14.0.6 available as llc (intentionally selected because it can produce V3), save this as /tmp/rea-repro/kernel.ll:

target triple = "amdgcn-amd-amdhsa"
define amdgpu_kernel void @add_one(i32 addrspace(1)* %out, i32 %value) {
entry:
  %result = add i32 %value, 1
  store i32 %result, i32 addrspace(1)* %out
  ret void
}

Produce the two objects and inspect the V3 header independently:

llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 --amdhsa-code-object-version=3 \
  -filetype=obj /tmp/rea-repro/kernel.ll -o /tmp/rea-repro/amd-v3.o
llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 --amdhsa-code-object-version=4 \
  -filetype=obj /tmp/rea-repro/kernel.ll -o /tmp/rea-repro/amd-v4.o
llvm-readelf --notes --file-header /tmp/rea-repro/amd-v3.o

From the source checkout with locked dependencies, set REA_CHECKOUT to the checkout and run this reduced form of the executed service probe with local tsx:

import { pathToFileURL } from 'node:url';
const root = process.env.REA_CHECKOUT!;
const { GpuCodeObjectsService } = await import(pathToFileURL(
  `${root}/src/application/gpu/GpuCodeObjectsService.ts`).href);
const { GpuCodeObjectsProvider } = await import(pathToFileURL(
  `${root}/src/gpu/GpuCodeObjectsProvider.ts`).href);
const service = new GpuCodeObjectsService(new GpuCodeObjectsProvider());
for (const [file, analysis, targets] of [
  ['amd-v3.o', 'inventory', undefined],
  ['amd-v3.o', 'kernels', undefined],
  ['amd-v3.o', 'kernels', ['amdgcn-amd-amdhsa--gfx900']],
  ['amd-v4.o', 'kernels', ['amdgcn-amd-amdhsa--gfx900']],
] as const) {
  const result = await service.inspect({ path: `/tmp/rea-repro/${file}`,
    analysis, detail: 'complete', ...(targets ? { targets } : {}) });
  if (!result.ok) throw result.error;
  console.log(result.value.normalized_result);
}
await service.close();

The full executed probe additionally selected the V3 inventory object ID with its expected_sha256; that successfully returned add_one. Both producer commands succeeded. The final service comparison reproduced once; the preceding comparison produced the same missing V3 target.

Expected behavior

Inventory should retain the processor declared by a supported AMDGPU V3 ELF header so callers can discover and select its target. Unavailable feature details can remain explicitly unknown.

REA's GPU guide presents target inventory as the starting workflow. LLVM's AMDGPU ABI places V3-and-later processor identity in EF_AMDGPU_MACH. Its V3 metadata definition has no amdhsa.target; that field is introduced by V4. A V3 object does not need a V4 note field to declare its processor.

Impact and scope

Observed on one real gfx900 V3 relocatable object. Its kernel metadata remains readable, but the primary target inventory loses the processor and exact target selection cannot select a null target. The V4 control works. Other processors, linked shared code objects and CLI/MCP transport were not tested.

Verified workaround for reading kernels: omit the target filter or select the inventoried object ID with its artifact SHA-256. This does not restore the missing processor inventory.

REA version

6.7.0; source revision 6a34be416b355e197aa2c1efe4b2f110abe47de4.

Runtime and platform

Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64. Producer: Debian LLVM 14.0.6, extracted into a temporary directory without installing it globally. Independent reader: LLVM 23.1.3. No GPU execution or device runtime was required.

Target and artifact context

LLVM-generated ELF64 little-endian AMDGPU relocatable objects for gfx900, code object V3 and V4; one owned add_one kernel.

Interface

Other

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Independent llvm-readelf result for V3:

OS/ABI: AMDGPU - HSA
ABI Version: 1
Machine: EM_AMDGPU
Flags: 0x12c, gfx900, xnack
amdhsa.version: [1, 0]

Selected observations from the executed service probe:

v3-inventory: target=null, inspection=inventory, discovery=partial
v3-all-kernels: target=null, inspection=complete, add_one, parameter_count=2, parameter_bytes=12
v3-exact-target-filter: target=null, inspection=not-selected, kernels=[]
v3-object-id-workaround: add_one, parameter_count=2, parameter_bytes=12
v4-control: target=amdgcn-amd-amdhsa--gfx900, inspection=complete, add_one

Typed outcome or recovery expected

A known processor target from the V3 header, preserving explicit uncertainty for any feature profile that cannot be established. Target inventory should not require the caller to decode the ELF header separately.

Analysis or suspected cause

Source-derived cause: the AMD metadata owner collects targets solely from amdhsa.target, without decoding the V3 processor flags. The inventory consumer receives null, and target selection excludes null targets.

Additional context

No known-good REA revision was established. This is distinct from descriptor exhaustion and PTX register-name handling. The supplied fixtures were generated locally from the shown kernel IR; no third-party target binary or GPU execution was used.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: A supported real V3 object loses its explicit processor during inventory, preventing the target-first selection workflow for that object while unfiltered kernel analysis still succeeds.
Workaround status: available
Workaround basis: The executed object-ID plus SHA-256 selection and unfiltered inspection both recovered the same kernel metadata; neither repairs the missing target fact itself.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6806 ## 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 GPU service inventories a real LLVM-produced AMDGPU V3 object as `target: null`, even though its ELF flags identify `gfx900`. Unfiltered kernel analysis returns `add_one`, two arguments and 12 argument bytes. Target-filtered analysis skips the same object and returns no kernels. An otherwise equivalent V4 producer control reports its target and returns the kernel when selected. This was reproduced through `GpuCodeObjectsService` and the production provider, without mocking the parser or filesystem. CLI/MCP transport was not exercised. ## Reproduction 1. With LLVM 14.0.6 available as `llc` (intentionally selected because it can produce V3), save this as `/tmp/rea-repro/kernel.ll`: ```llvm target triple = "amdgcn-amd-amdhsa" define amdgpu_kernel void @add_one(i32 addrspace(1)* %out, i32 %value) { entry: %result = add i32 %value, 1 store i32 %result, i32 addrspace(1)* %out ret void } ``` 2. Produce the two objects and inspect the V3 header independently: ```sh llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 --amdhsa-code-object-version=3 \ -filetype=obj /tmp/rea-repro/kernel.ll -o /tmp/rea-repro/amd-v3.o llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx900 --amdhsa-code-object-version=4 \ -filetype=obj /tmp/rea-repro/kernel.ll -o /tmp/rea-repro/amd-v4.o llvm-readelf --notes --file-header /tmp/rea-repro/amd-v3.o ``` 3. From the source checkout with locked dependencies, set `REA_CHECKOUT` to the checkout and run this reduced form of the executed service probe with local `tsx`: ```ts import { pathToFileURL } from 'node:url'; const root = process.env.REA_CHECKOUT!; const { GpuCodeObjectsService } = await import(pathToFileURL( `${root}/src/application/gpu/GpuCodeObjectsService.ts`).href); const { GpuCodeObjectsProvider } = await import(pathToFileURL( `${root}/src/gpu/GpuCodeObjectsProvider.ts`).href); const service = new GpuCodeObjectsService(new GpuCodeObjectsProvider()); for (const [file, analysis, targets] of [ ['amd-v3.o', 'inventory', undefined], ['amd-v3.o', 'kernels', undefined], ['amd-v3.o', 'kernels', ['amdgcn-amd-amdhsa--gfx900']], ['amd-v4.o', 'kernels', ['amdgcn-amd-amdhsa--gfx900']], ] as const) { const result = await service.inspect({ path: `/tmp/rea-repro/${file}`, analysis, detail: 'complete', ...(targets ? { targets } : {}) }); if (!result.ok) throw result.error; console.log(result.value.normalized_result); } await service.close(); ``` The full executed probe additionally selected the V3 inventory object ID with its `expected_sha256`; that successfully returned `add_one`. Both producer commands succeeded. The final service comparison reproduced once; the preceding comparison produced the same missing V3 target. ## Expected behavior Inventory should retain the processor declared by a supported AMDGPU V3 ELF header so callers can discover and select its target. Unavailable feature details can remain explicitly unknown. [REA's GPU guide](https://github.com/morluto/rea/blob/6a34be416b355e197aa2c1efe4b2f110abe47de4/docs/gpu-code-objects.md#L3-L18) presents target inventory as the starting workflow. [LLVM's AMDGPU ABI](https://llvm.org/docs/AMDGPUUsage.html#amdgpu-elf-header) places V3-and-later processor identity in `EF_AMDGPU_MACH`. Its [V3 metadata definition](https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-metadata) has no `amdhsa.target`; that field is introduced by V4. A V3 object does not need a V4 note field to declare its processor. ## Impact and scope Observed on one real `gfx900` V3 relocatable object. Its kernel metadata remains readable, but the primary target inventory loses the processor and exact target selection cannot select a null target. The V4 control works. Other processors, linked shared code objects and CLI/MCP transport were not tested. Verified workaround for reading kernels: omit the target filter or select the inventoried object ID with its artifact SHA-256. This does not restore the missing processor inventory. ## REA version 6.7.0; source revision `6a34be416b355e197aa2c1efe4b2f110abe47de4`. ## Runtime and platform Node.js v24.22.1; Linux 7.2.8-9-omarchy x86_64. Producer: Debian LLVM 14.0.6, extracted into a temporary directory without installing it globally. Independent reader: LLVM 23.1.3. No GPU execution or device runtime was required. ## Target and artifact context LLVM-generated ELF64 little-endian AMDGPU relocatable objects for `gfx900`, code object V3 and V4; one owned `add_one` kernel. ## Interface Other ## Earliest failure stage Native analysis or reconstruction ## Relevant output or evidence Independent `llvm-readelf` result for V3: ```text OS/ABI: AMDGPU - HSA ABI Version: 1 Machine: EM_AMDGPU Flags: 0x12c, gfx900, xnack amdhsa.version: [1, 0] ``` Selected observations from the executed service probe: ```text v3-inventory: target=null, inspection=inventory, discovery=partial v3-all-kernels: target=null, inspection=complete, add_one, parameter_count=2, parameter_bytes=12 v3-exact-target-filter: target=null, inspection=not-selected, kernels=[] v3-object-id-workaround: add_one, parameter_count=2, parameter_bytes=12 v4-control: target=amdgcn-amd-amdhsa--gfx900, inspection=complete, add_one ``` ## Typed outcome or recovery expected A known processor target from the V3 header, preserving explicit uncertainty for any feature profile that cannot be established. Target inventory should not require the caller to decode the ELF header separately. ## Analysis or suspected cause Source-derived cause: [the AMD metadata owner](https://github.com/morluto/rea/blob/6a34be416b355e197aa2c1efe4b2f110abe47de4/src/gpu/GpuElfKernels.ts#L375-L383) collects targets solely from [`amdhsa.target`](https://github.com/morluto/rea/blob/6a34be416b355e197aa2c1efe4b2f110abe47de4/src/gpu/GpuElfKernels.ts#L416-L425), without decoding the V3 processor flags. [The inventory consumer](https://github.com/morluto/rea/blob/6a34be416b355e197aa2c1efe4b2f110abe47de4/src/gpu/GpuInventory.ts#L473-L479) receives null, and [target selection](https://github.com/morluto/rea/blob/6a34be416b355e197aa2c1efe4b2f110abe47de4/src/gpu/GpuInventory.ts#L120-L126) excludes null targets. ## Additional context No known-good REA revision was established. This is distinct from descriptor exhaustion and PTX register-name handling. The supplied fixtures were generated locally from the shown kernel IR; no third-party target binary or GPU execution was used. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: A supported real V3 object loses its explicit processor during inventory, preventing the target-first selection workflow for that object while unfiltered kernel analysis still succeeds. - Workaround status: available - Workaround basis: The executed object-ID plus SHA-256 selection and unfiltered inspection both recovered the same kernel metadata; neither repairs the missing target fact itself.

bsakaguchi closed this issue

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

bsakaguchi referenced this issue

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

[PR #4154] [CLOSED] test(verifiers): expand tar listing identity coverage #6093