Anatomy of a CUDA Binary

NVIDIA's CUDA binary format (cubin) is an ELF64 file with undocumented NVIDIA-specific sections that encode kernel machine code, parameter layout, and metadata. A reverse-engineering analysis reveals the section layout, EIATTR metadata encoding, and constant bank conventions for sm_100 (B200) hardware, based on validation against ptxas output. The findings are critical for developers building custom cubin emitters or understanding CUDA driver requirements.

Anatomy of a CUDA Binary When you compile a CUDA kernel, the final artifact is a cubin — a CUDA binary. It is a standard ELF64 file with NVIDIA-specific sections that encode everything the CUDA driver needs to load and launch a kernel: the machine code, the parameter layout, register allocation metadata, and a collection of attributes that have no public documentation. This post walks through the section layout of a cubin, explains the .nv.info metadata format that makes a kernel self-describing, and shows how these pieces connect at the byte level. The material is drawn from building a from-scratch cubin emitter and validating it against ptxas output on B200 silicon. A note on methodology:Everything in this article is based on my analysis of cubins produced by ptxas and validated on real hardware. Nvidia does not publish a specification for the cubin section layout, the .nv.info EIATTR encoding, or the constant bank parameter conventions described here. The structures and semantics are reverse-engineered from compiled binaries. Readers should verify against their own cubins and toolkit versions. The ELF Container A cubin is an ELF64 executable. The header identifies it: 1 2 3 4 5 e ident EI OSABI = 0x41 CUDA ABI, not the older 0x33 e ident EI ABIVERSION = 8 e type = ET EXEC loadable, not relocatable e machine = EM CUDA 0xBE e flags = 0x06006402 for sm 100, 64-bit addressing The e flags field encodes the SM architecture in bits 8–15. For sm 100 B200 , that is 0x64 = 100 decimal. Bit 1 marks 64-bit addressing. Bits 24–26 carry a format version that the driver checks. Older cubins used ELFOSABI CUDA = 0x33 with ABI version 0. The CUDA 13 driver rejects these — cuModuleGetFunction returns CUDA ERROR NOT SUPPORTED . If you are emitting cubins from scratch, the ABI version matters. Section Layout A single-kernel cubin contains roughly twelve sections. We will use a minimal kernel as the running example — an integer add, written in LLVM IR: 1 2 3 4 define i32 @add i32 %a, i32 %b { %c = add i32 %a, %b ret i32 %c } Compiling this with llc -march=sass -filetype=obj produces a relocatable CUDA ELF. After finalization, the cubin contains these sections: | | Section | Type | Purpose | |---|---|---|---| | 0 | null | SHT NULL | ELF convention | | 1 | .text.add | SHT PROGBITS | SASS machine code 128-bit instructions | | 2 | .nv.constant0.add | SHT PROGBITS | Constant bank 0 parameter region | | 3 | .nv.info | SHT LOPROC | Module-level metadata EIATTR stream | | 4 | .nv.info.add | SHT LOPROC | Per-kernel metadata EIATTR stream | | 5 | .note.nv.cuver | SHT NOTE | CUDA version note | | 6 | .note.nv.tkinfo | SHT NOTE | Toolkit release note | | 7 | .nv.compat | 0x70000086 | SM compatibility descriptor | | 8 | .nv.callgraph | 0x70000001 | Intra-module call graph | | 9 | .symtab | SHT SYMTAB | Symbol table | | 10 | .strtab | SHT STRTAB | String table | | 11 | .shstrtab | SHT STRTAB | Section-name string table | The sections fall into four categories: the executable code, the kernel ABI metadata, driver compatibility notes, and the standard ELF bookkeeping. This is the minimal set. A real cubin produced by ptxas for a production kernel is larger — typically ~22 sections, 8 symbols, and 5 program headers. One notable addition is .nv.shared.reserved.0 , a SHT NOBITS section 64 bytes that reserves shared memory space. It comes with two weak symbols .nv.reservedSmem.offset0 and nv reservedSMEM offset 0 alias and its own PT LOAD program header. Other additional sections include .nv.shared.<kernel shared memory allocation , .nv.global global variable metadata , .nv.constant2.<kernel compiler-generated constant data , .debug sections DWARF debug info when compiled with -G , and .rel. relocation sections. The table above covers the sections that are structurally required for any kernel to load and execute. .text.<kernel — The Machine Code The .text.add section contains the SASS instructions. Each instruction is a 128-bit 16-byte word. The section flags are SHF ALLOC | SHF EXECINSTR — SHF ALLOC means the section occupies memory at runtime the driver must load it onto the GPU , and SHF EXECINSTR marks it as containing executable machine instructions. The section is aligned to 128 bytes. 1 2 3 Bits 0..104: instruction body opcode, operands, modifiers Bits 105..121: scheduling control stall, yield, barriers Bits 122..125: operand reuse flags The kernel’s entry symbol is a STT FUNC in the symtab with st other = 0x10 STO CUDA ENTRY , pointing at the start of this section. The driver uses STO CUDA ENTRY to distinguish kernel entry points from device functions. .nv.constant0.<kernel — The Constant Bank Kernel parameters are passed through constant bank 0. The section .nv.constant0.add is a SHT PROGBITS section sized to cover the parameter region: 1 size = param base + param size The param base is set by the CUDA toolkit — not a fixed ISA constant. The values observed on current toolkits are: | SM range current toolkit | param base | |---|---| | sm 70 – sm 89 Volta through Ampere | 0x160 352 bytes | | sm 90 Hopper | 0x210 528 bytes | | sm 100 – sm 12x Blackwell | 0x380 896 bytes | These values can shift across toolkit versions for the same architecture. We have observed a sibling slot in the constant bank the memory-descriptor offset move from 0x208 to 0x220 for sm 90 between CUDA 11 and CUDA 12, confirming that the layout is a toolkit convention, not an architectural invariant. The first param base bytes are reserved for driver-managed metadata grid dimensions, block dimensions, shared memory size, etc. . User-specified kernel parameters are laid out contiguously starting at param base , each aligned to its ABI alignment. For a kernel add int a, int b , the two 4-byte parameters occupy offsets 0x0 and 0x4 relative to param base . The total section size is 0x380 + 8 = 0x388 on sm 100. The code reads parameters with LDC load constant instructions: 1 2 LDC R0, c 0x0 param base + 0x0 // load 'a' LDC R1, c 0x0 param base + 0x4 // load 'b' The .nv.info metadata, the constant bank section, and the LDC instructions must all agree on the base offset. If they disagree, the driver copies launch arguments to one offset and the kernel reads from another — wrong results, no crash, no diagnostic. .nv.info — The EIATTR Metadata Format The .nv.info sections are the most opaque part of a cubin. They use SHT LOPROC 0x70000000 , a processor-specific section type. The content is a flat stream of EIATTR ELF Info ATTRibute entries. There is no public documentation for this format. Each EIATTR entry has a fixed 4-byte header: 1 2 3 byte 0: format EIFMT byte 1: attribute code EIATTR byte 2-3: value or size depends on format The format byte determines how the value is encoded: | EIFMT | Value | Encoding | |---|---|---| EIFMT NVAL | 1 | No value. Bytes 2–3 are zero padding. | EIFMT BVAL | 2 | One inline byte in byte 2. Byte 3 is padding. | EIFMT HVAL | 3 | 16-bit inline value in bytes 2–3 little-endian . | EIFMT SVAL | 4 | Bytes 2–3 are a 16-bit size N. N bytes of payload follow immediately. | This is a TLV type-length-value 1 scheme, except the “length” is implicit for formats 1–3 always 4 bytes total and explicit only for format 4. Module-Level .nv.info The module-level .nv.info section no kernel suffix contains attributes keyed by symbol index. For each kernel, it emits three entries: REGCOUNT 0x2f : The number of general-purpose registers the kernel uses. Format is EIFMT SVAL with an 8-byte payload: symbol index:u32, regcount:u32 . For a kernel add that touches registers R0 and R1 , the regcount is 2: 1 2 3 4 5 6 04 2f 08 00 03 00 00 00 02 00 00 00 │ │ │ │ └─ regcount = 2 │ │ │ └─ symbol index = 3 the kernel entry │ │ └─ payload size = 8 bytes │ └─ EIATTR REGCOUNT = 0x2f └─ EIFMT SVAL = 4 FRAME SIZE 0x11 : Stack frame size in bytes. Same 8-byte keyed format. Zero for a leaf kernel. MIN STACK SIZE 0x12 : Minimum stack size. Also zero for a leaf kernel. The driver uses regcount to compute occupancy — how many thread blocks can run concurrently on one SM. Over-reporting wastes occupancy. Under-reporting causes the hardware to clobber live registers. Per-Kernel .nv.info.<kernel The per-kernel section carries the kernel’s ABI contract with the driver. The entries, in order: SW INFO 0x37 : Software info. An EIFMT SVAL with a 4-byte payload containing the section’s own byte size. Self-referential — you compute the size, write it, and the size includes the bytes you just wrote. In practice, this means building the section twice. Attribute 0x35: An EIFMT NVAL flag that ptxas emits before PARAM CBANK . Its exact semantics are unclear; omitting it does not affect loading, but real cubins always include it. PARAM CBANK 0x0a : Constant bank descriptor. EIFMT SVAL , 8-byte payload: 1 cbank symbol index:u32, param size << 16 | param base : u32 This tells the driver which symbol table entry identifies the constant bank section, how large the parameter region is, and where it starts within the bank. For add int, int on sm 100: 1 2 3 4 cbank sym = 2 section symbol for .nv.constant0.add param base = 0x380 param size = 8 two i32s packed = 8 << 16 | 0x380 = 0x00080380 CBANK PARAM SIZE 0x19 : An EIFMT HVAL with the parameter region size as a 16-bit value. Redundant with the high half of PARAM CBANK , but ptxas always emits both. KPARAM INFO 0x17 : One entry per kernel parameter, emitted in reverse ordinal order highest ordinal first — this matches ptxas output . Each is EIFMT SVAL with a 12-byte payload: 1 index:u32, ordinal:u16, offset:u16, packed:u32 The packed field encodes size << 18 | 0x1f000 . The 0x1f000 constant carries the parameter space and log-alignment for by-value parameters. For a 4-byte int parameter: packed = 4 << 18 | 0x1f000 = 0x0011f000 . MAXREG COUNT 0x1b : An EIFMT HVAL with the maximum register count hint usually 0xff = no limit . EXIT INSTR OFFSETS 0x1c : An EIFMT SVAL listing the byte offsets of every EXIT instruction in the .text section. The driver likely uses these for pre-emption — knowing where a kernel can cleanly yield control — though the exact use is not documented. Each offset is a u32 . For a kernel whose EXIT is the 5th instruction offset 4 16 = 0x40 : 1 2 3 4 5 04 1c 04 00 40 00 00 00 │ │ │ └─ EXIT at byte offset 0x40 │ │ └─ payload size = 4 │ └─ EIATTR EXIT INSTR OFFSETS = 0x1c └─ EIFMT SVAL = 4 The Note Sections Two ELF note sections carry driver compatibility information: .note.nv.cuver note type 0x3e8 : A 12-byte descriptor encoding the SM architecture and a format version. The CUDA driver checks this to determine if the cubin is compatible with the current GPU. .note.nv.tkinfo note type 0x7d0 : The toolkit release string. Contains the ptxas version, the CUDA release string e.g., “Cuda compilation tools, release 12.8, V12.8.93” , and the compilation flags -arch sm 100 -m 64 . The driver validates this to reject cubins compiled with unsupported toolkit versions.Both use the standard ELF note format: namesz, descsz, type header, followed by the vendor name “NVIDIA Corp” NUL-terminated, 4-byte padded , followed by the descriptor. .nv.callgraph and .nv.compat .nv.callgraph type 0x70000001 : Encodes the intra-module call graph. For a leaf kernel no device function calls , this contains four entries: the kernel node id 0 connected to four sentinel edges 0xffffffff through 0xfffffffc that mark it as a call-graph leaf. .nv.compat type 0x70000086 : An SM compatibility descriptor. For a single-architecture cubin, this is a fixed 16-byte block encoding feature-level requirements. The Symbol Table The cubin’s .symtab contains four entries for a single-kernel module: | Index | Type | Other | Section | Name | Purpose | |---|---|---|---|---|---| | 0 | STT NOTYPE | 0 | SHN UNDEF | null | ELF convention | | 1 | STT SECTION | 0 | .text.add | — | Section symbol for .text | | 2 | STT SECTION | 0 | .nv.constant0.add | — | Section symbol for constant bank | | 3 | STT FUNC | 0x10 | .text.add | add | Kernel entry point | The st other = 0x10 STO CUDA ENTRY on the kernel symbol is what distinguishes a kernel entry from a device function. The .nv.info entries reference symbols by index — REGCOUNT references symbol 3, PARAM CBANK references symbol 2 — so the indices must be stable. Putting It Together Here is the complete flow from source to loaded kernel: php flowchart LR A ".cu source" -- B "ptxas / llc" B -- C "cubin ELF64 " C -- D "cuModuleLoad" D -- E "Driver reads sections" E -- F ".nv.info → regcount,<br/ params, exits" E -- G ".nv.constant0 → allocate<br/ param bank" E -- H ".text → load SASS<br/ to SM" F -- I "Compute occupancy,<br/ register EXIT offsets" G -- J "Copy launch args<br/ to param base" H -- K "Execute" The driver’s loading sequence: - Parse the ELF header. Check e flags for SM compatibility. - Validate the .note.nv.cuver and .note.nv.tkinfo notes. - Read the .nv.info stream: extract regcount, frame size, stack size. - Read .nv.info.<kernel : extract parameter layout, constant bank descriptor, EXIT offsets. - Allocate constant bank memory. Copy host-side launch arguments to param base within it. - Load .text into instruction memory on the target SM. - Configure the warp scheduler with the register count for occupancy and EXIT offsets. - Launch. If any of these metadata sections are malformed or inconsistent, the behavior ranges from CUDA ERROR INVALID IMAGE to silent wrong results — there is no “metadata validation” pass that checks cross-section consistency before launch. What This Means in Practice For most CUDA developers, the cubin is an opaque blob that nvcc produces and the driver consumes. But the structure matters when: You want to understand the internals of a SASS binary. For most CUDA developers, the cubin is a black box. Knowing the section layout — what .nv.info encodes, how the constant bank is sized, where the driver finds EXIT offsets — turns it into something you can read and reason about. Debugging and performance analysis. This is a crucial skill for both. When a kernel silently produces wrong results, the .nv.info stream is the authoritative record of what ptxas decided: how many registers, where the parameters live, which instructions are exits. When occupancy is lower than expected, the regcount in .nv.info tells you why. Reading these sections directly rather than trusting cuobjdump ’s summary gives you the ground truth. Portability of compiled cubins. The constant bank parameter base has changed silently across toolkit versions: 0x160 on Volta through Ampere, 0x210 on Hopper, 0x380 on Blackwell on current toolkits . None of this is documented, and the values are toolkit conventions that can shift even within a single architecture across CUDA releases. A cubin compiled with one toolkit version cannot be assumed portable to another, because the code LDC offsets , the .nv.info PARAM CBANK , and the .nv.constant0 section size all encode the base independently. If they disagree, the driver copies launch arguments to one offset and the kernel reads from another. References Disclaimer: This article was generated using the Gemini 3.1 Pro and Claude Opus 4.8 models. CC BY 4.0 https://creativecommons.org/licenses/by/4.0/ by the author.