NVCC embeds the raw CUDA fat binary blob in the host-side x86 assembly
inside a `#APP`/`#NO_APP` inline-assembly block under the label
`fatbinData`. In a realistic kernel this can be 100+ lines of `.quad`
hex values — a wall of noise before any user-readable code.
The fix adds a per-compiler pre-processing step in `NvccCompiler`:
before the host assembly is passed to the ASM parser, any `#APP`/`#NO_APP`
block that contains a `.nv_fatbin` section is stripped out entirely.
Only those blocks are removed; genuine user inline-assembly blocks (which
also use `#APP`/`#NO_APP` but do not contain `.nv_fatbin`) are left
intact.
This approach is intentionally NVCC-specific (in `NvccCompiler`, not the
base `AsmParser`) so there is no risk of false positives for other
compilers. The blob is stripped before `findUsedLabels` runs, so the
`fatbinData` label naturally disappears as unreferenced without needing
any special-casing in the parser's label-filtering logic.
Filtering is gated on the existing Labels filter, matching user
expectations: with no filters active everything is visible; with the
Labels filter on the fat binary blob disappears.
Testing:
- `test/compilers/nvcc-tests.ts` — five unit tests for
`removeNvccFatbinaryBlob()`: strips fat-binary blocks, preserves
user inline-asm blocks, handles multiple mixed blocks, no-op with no
APP blocks, gracefully handles malformed unclosed blocks.
- `test/filters-cases/nvcc-x86-host-example.asm` — representative NVCC
12.0 host assembly (real 15-line fat binary, boilerplate functions,
`.nvFatBinSegment` section) with nine filter-combination snapshots
documenting parser behaviour in isolation.
Closes#5178🤖 Generated by LLM (Claude, via OpenClaw)
0c21e98bbb