NVIDIA ELF Section Catalog

Complete alphabetical catalog of every ELF section name recognized by nvlink v13.0.88. Sections are grouped by category. Each table shows the section name, the sh_type as both a hex value and its symbolic constant, and the section's purpose. For detailed semantics, see NVIDIA Section Types.

Notation conventions:

• <funcname> -- kernel or device function name suffix (e.g., .text._Z6kernelPf).
• <secname> -- target section name (e.g., .rela.text._Z6kernelPf).
• (prefix) -- the string in the binary is a prefix used with strncmp; the full name is formed by appending a suffix at runtime.
• Format strings like .rela%s show how nvlink constructs the name via sprintf.

Code Sections

Info and Metadata

Relocation Sections

Global Memory

Local Memory (Per-Thread)

String in binary: .nv.local. (prefix; function name appended at runtime).

Shared Memory (Per-CTA)

String in binary: .nv.shared. (prefix; function name appended at runtime).

Constant Memory (Banks 0--17)

Bank type formula: SHT_CUDA_CONSTANT0 + N = 0x70000064 + N. The bank number is parsed from the section name suffix by strtol(name + 12, NULL, 10). Per-entry constant sections use the naming convention <bank>.<funcname> (e.g., .nv.constant0.my_kernel).

The generic prefix .nv.constant (without a bank digit) also appears in the binary and is matched by strncmp. See Constant Banks.

Named Constant Aliases

These are logical names for constant memory regions within specific banks. They appear as section name suffixes (e.g., .nv.constant0.entry_params) or as standalone lookup keys.

Unified Tables (UFT/UDT/UIDX)

Texture and Surface Descriptors

Note Sections

Debug Sections -- NVIDIA Proprietary

The prefix .nv_debug_ appears in the binary as a string used with strncmp to recognize sections. The linker constructs .nv_debug_line_sass programmatically via section_create.

Debug Sections -- Standard DWARF

The linker recognizes any section with prefix .debug_ as a standard DWARF section. Common instances in cubins:

The string .debug_ appears as a prefix matcher. The variant .debug_str+ also appears in the binary (used internally for merged/concatenated debug string pools).

Hash Relocation Sections (Incremental Linking)

These sections support incremental linking through hash-based relocation tracking. Each letter encodes the content type: Key, Code, Data; and the scope: External, Internal. Processed by hrk_section_process (sub_4AF3C0) and hrc_hrd_section_process (sub_4B02A0).

Mercury Sections (sm100+)

All Mercury sections carry SHF_CUDA_MERCURY (0x10000000) in sh_flags. The merge phase skips them; FNLZR processes them after finalizing Mercury instructions into SASS. See Mercury ELF Sections.

Mercury Container

Mercury DWARF Debug

Mercury NVIDIA Debug

Mercury Structural

Fatbin Sections (Host ELF)

These sections appear in the host-side ELF, not in the device cubin. The linker script template embeds them:

SECTIONS {
    .nvFatBinSegment : { *(.nvFatBinSegment) }
    __nv_relfatbin   : { *(__nv_relfatbin) }
    .nv_fatbin       : { *(.nv_fatbin) }
}

Standard ELF Infrastructure

Section Type Summary

NVIDIA CUDA-Specific Types (0x70000000--0x70000087)

Each row lists the value as it is actually passed to sub_441AC0 (the section creator) in the decompiled code. The constant names are synthetic -- NVIDIA does not publish a public header with SHT_CUDA_* identifiers -- but the hex values are verbatim from the decompiled function bodies.

Standard ELF Types Used

Section Flag Summary

String-to-Section Cross-Reference

Every section-name string found in the nvlink v13.0.88 binary that matches ELF section patterns, listed alphabetically. This serves as a completeness check against the catalog above.

Total: 109 cataloged section entries (numbered #1--#109), covering all 95 distinct section-name strings found in the nvlink binary plus 14 per-bank constant entries (.nv.constant1--.nv.constant17 share the same pattern but have distinct string literals in the binary).

Cross-References

Internal (nvlink wiki):

• NVIDIA Section Types -- Detailed semantics for each section category: type constants, flags, merge handlers, and lifecycle
• Constant Banks -- Deep dive on .nv.constant* sections: bank numbering, dedup, hardware limits
• .nv.info Metadata -- EIATTR attribute format and the 90+ constants carried in .nv.info sections
• Unified Function Tables -- UFT/UDT section management for .nv.uft, .nv.udt, .nv.uidx
• Mercury ELF Sections -- The 19 .nv.merc.* Mercury sections (entries #84--#102)
• R_CUDA Catalog -- Relocation type catalog for relocations referencing these sections
• Section Merging -- merge_elf name-prefix dispatch that classifies input sections
• Device ELF Format -- ELF header and standard infrastructure sections (.symtab, .strtab, .shstrtab)

Sibling wikis:

• ptxas: Sections -- How ptxas creates the sections that nvlink consumes and merges
• ptxas: EIATTR Reference -- EIATTR constants that populate .nv.info sections

Confidence Assessment

Verification scope: All 109 catalog entries were cross-checked against nvlink_strings.json (96 NVIDIA/fatbin-section strings total). The first argument passed to the section creator sub_441AC0(elf_ctx, name, sh_type, flags, link, info, entsize, align) was compared to the sh_type column for 13 sections by reading the decompiled call sites.

Totals: 109 catalog rows covering 95 distinct section-name strings. Name verification: 95 / 95 strings found verbatim in nvlink_strings.json. sh_type verification: 16 spot-checked, all 16 now match the catalog after the P081 correction pass that re-derived every NVIDIA-specific value from the sub_441AC0 creation sites listed in the table below.

Section-name spot checks (10 of 95)

sh_type verification table (post-P081 correction)

Every NVIDIA-specific sh_type in the catalog was re-derived from the sub_441AC0(ctx, name, sh_type, ...) argument in the decompiled creation site. The table below records the verification and stands as the authoritative source for the main catalog tables above.

P081 correction history: An earlier revision of this catalog assigned sh_type values via a flawed sequential increment pattern starting from .nv.info = 0x70000001. The correct assignment begins at .nv.info = 0x70000000 and is not contiguous -- four identifiers in the 0x70000005--0x7000000D range are unused in the nvlink creator, and .nv.compat / .nv.host live in a separate 0x70000086--0x70000087 block. All wrong values from that pattern have been replaced with the actual arguments observed in the sub_441AC0 calls cited above.

Cross-reference with the ptxas Sections page: ptxas also uses SHT_CUDA_INFO = 0x70000000, which is consistent with nvlink's creator. The ptxas wiki's earlier claim that SHT_CUDA_CALLGRAPH = 0x70000064 conflicts with nvlink's 0x70000001 -- the ptxas wiki entry at that page (line 90) still needs correction.