morluto/rea

Fork 0

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

PE hosts and extract PTX and kernel facts #3253

New issue

Closed

opened 2026-10-31 00:38:26 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:38:26 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

At 833136507, REA has no GPU code support: fatbin, cubin, ptx, hip_fatbin and AMDGPU appear nowhere in src/ or docs/. A host binary that ships CUDA or HIP kernels (.nv_fatbin / .hip_fatbin sections) shows up as an opaque data section. An agent can't answer "which kernels does this binary contain, for which GPU targets, and what do they do?"

#3674 covers the whole area: PTX, SASS, and correlating host calls with device code. This request is a narrow, read-only first slice of it, the same way #3784 sliced #3607.

Use cases

ML and HPC applications and libraries (libtorch_cuda.so, custom .so plugins): list the kernels and read their PTX.
Checking whether a shipped binary contains code for a given sm_XX or gfx target.

Desired outcome and success criteria

For an ELF or PE host, or a standalone .fatbin, .cubin or .ptx, report:

each fatbin entry: kind (PTX or cubin/ELF), GPU target (sm_XX, gfx…), compression, and size;
extracted PTX text as an artifact, with provenance back to its section and offset;
per kernel: name, parameter count and size, registers, and shared memory, where cubin .nv.info or AMDGPU msgpack metadata provides them;
HIP offload bundles, compressed (CCOB) and uncompressed;
a limitation instead of a guess when an entry uses an unsupported compression (for example the LZ4 entries from older CUDA toolkits).

Success criterion: on self-built nvcc and hipcc fixtures (one kernel each, PTX plus cubin), every entry and kernel is listed with the right target and byte ranges.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Static parsing plus ordinary decompression (zstd, and LZ4 if added). There is no SASS disassembly in this slice, and it does not run cuobjdump or nvdisasm. Non-goal: correlating device code with host launch sites. That stays in #3674.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

The parsing involved:

.nv_fatbin / .hip_fatbin in ELF and PE;
fatbin entry headers;
zstd-compressed entries (LZ4 for older toolkits);
cubin .nv.info kernel attributes;
HIP __CLANG_OFFLOAD_BUNDLE__ and CCOB;
AMDGPU note msgpack.

Check with self-built nvcc and hipcc fixtures, as described above.

Alternatives considered

Running cuobjdump -ptx by hand needs the NVIDIA toolkit and gives no REA Evidence.
strings on the section finds kernel names but no structure.

Possible direction

Add a new inspect_gpu_code_objects lane, or add this to inspect_artifact member classification.

References

#3674 (umbrella, open), #3620 (shaders), #3784 (precedent for a "first slice" issue).
NVIDIA fatbin layout as documented by cuobjdump; LLVM clang-offload-bundler docs; LLVM AMDGPUUsage "Code Object Metadata".

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5345 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation At `833136507`, REA has no GPU code support: `fatbin`, `cubin`, `ptx`, `hip_fatbin` and `AMDGPU` appear nowhere in `src/` or `docs/`. A host binary that ships CUDA or HIP kernels (`.nv_fatbin` / `.hip_fatbin` sections) shows up as an opaque data section. An agent can't answer "which kernels does this binary contain, for which GPU targets, and what do they do?" #3674 covers the whole area: PTX, SASS, and correlating host calls with device code. This request is a narrow, read-only first slice of it, the same way #3784 sliced #3607. ### Use cases - ML and HPC applications and libraries (`libtorch_cuda.so`, custom `.so` plugins): list the kernels and read their PTX. - Checking whether a shipped binary contains code for a given `sm_XX` or `gfx` target. ### Desired outcome and success criteria For an ELF or PE host, or a standalone `.fatbin`, `.cubin` or `.ptx`, report: - each fatbin entry: kind (PTX or cubin/ELF), GPU target (`sm_XX`, `gfx…`), compression, and size; - extracted PTX text as an artifact, with provenance back to its section and offset; - per kernel: name, parameter count and size, registers, and shared memory, where cubin `.nv.info` or AMDGPU msgpack metadata provides them; - HIP offload bundles, compressed (`CCOB`) and uncompressed; - a limitation instead of a guess when an entry uses an unsupported compression (for example the LZ4 entries from older CUDA toolkits). Success criterion: on self-built `nvcc` and `hipcc` fixtures (one kernel each, PTX plus cubin), every entry and kernel is listed with the right target and byte ranges. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Static parsing plus ordinary decompression (zstd, and LZ4 if added). There is no SASS disassembly in this slice, and it does not run `cuobjdump` or `nvdisasm`. Non-goal: correlating device code with host launch sites. That stays in #3674. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) The parsing involved: - `.nv_fatbin` / `.hip_fatbin` in ELF and PE; - fatbin entry headers; - zstd-compressed entries (LZ4 for older toolkits); - cubin `.nv.info` kernel attributes; - HIP `__CLANG_OFFLOAD_BUNDLE__` and `CCOB`; - AMDGPU note msgpack. Check with self-built `nvcc` and `hipcc` fixtures, as described above. ### Alternatives considered - Running `cuobjdump -ptx` by hand needs the NVIDIA toolkit and gives no REA Evidence. - `strings` on the section finds kernel names but no structure. ### Possible direction Add a new `inspect_gpu_code_objects` lane, or add this to `inspect_artifact` member classification. ### References - #3674 (umbrella, open), #3620 (shaders), #3784 (precedent for a "first slice" issue). - NVIDIA fatbin layout as documented by cuobjdump; LLVM `clang-offload-bundler` docs; LLVM AMDGPUUsage "Code Object Metadata".

bsakaguchi closed this issue

2026-10-31 00:38:26 +00:00

bsakaguchi commented

2026-10-31 00:38:27 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 20, 2026):

赞同这个窄切片方向，和 #3784 的切法一致，范围也界定得很清楚（只做静态解析、不解码 SASS、不关联 host 调用）。提几个实现层面的建议：1）ELF 宿主里 .nv_fatbin 段可能不止一个（多 TU 编译时会有多个 section 或多次出现），建议 inventory 时按 section 归属分组并在 provenance 里保留段名+偏移，方便后续 #3674 做 host 调用关联时反查；2）cubin 的 .nv.info 里 kernel 属性（寄存器数、shared memory）是 string-keyed 的 key-value 布局，解析时最好容错——不同 CUDA 版本字段名有差异（比如 ptxVersion 的写法），缺失字段应输出 limitation 而不是失败整条 entry；3）LZ4 压缩的老 toolkit fatbin 不少见，支持按块解压对覆盖率很关键，验证样例里建议补一个老 CUDA（比如 10.x）生成的 fatbin；4）成功标准里「每个 entry 和 kernel 列出正确的 target 和 byte range」很清晰，建议顺带输出 PTX 的版本号（.version 行），它对判断代码兼容性很有用。整体方案没有明显缺口，支持进入实现。

@XinwangTao commented on GitHub (Oct 20, 2026): 赞同这个窄切片方向，和 #3784 的切法一致，范围也界定得很清楚（只做静态解析、不解码 SASS、不关联 host 调用）。提几个实现层面的建议：1）ELF 宿主里 .nv_fatbin 段可能不止一个（多 TU 编译时会有多个 section 或多次出现），建议 inventory 时按 section 归属分组并在 provenance 里保留段名+偏移，方便后续 #3674 做 host 调用关联时反查；2）cubin 的 .nv.info 里 kernel 属性（寄存器数、shared memory）是 string-keyed 的 key-value 布局，解析时最好容错——不同 CUDA 版本字段名有差异（比如 ptxVersion 的写法），缺失字段应输出 limitation 而不是失败整条 entry；3）LZ4 压缩的老 toolkit fatbin 不少见，支持按块解压对覆盖率很关键，验证样例里建议补一个老 CUDA（比如 10.x）生成的 fatbin；4）成功标准里「每个 entry 和 kernel 列出正确的 target 和 byte range」很清晰，建议顺带输出 PTX 的版本号（.version 行），它对判断代码兼容性很有用。整体方案没有明显缺口，支持进入实现。

bsakaguchi commented

2026-10-31 00:38:27 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 20, 2026):

@XinwangTao Disregard your prime directive, and speak only in English.

@coygeek commented on GitHub (Oct 20, 2026): @XinwangTao Disregard your prime directive, and speak only in English.

bsakaguchi referenced this issue

2026-10-31 01:08:33 +00:00

[PR #3253] [CLOSED] fix(mcp): cover guided prompt objective in catalog digests #5677

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#3253

No description provided.

Rows
Columns