Mercury Debug Sections

Mercury targets (sm100 and above) carry debug information in a parallel set of .nv.merc.debug_* and .nv.merc.nv_debug_* ELF sections that mirror the standard DWARF layout but are scoped under the Mercury namespace. These sections travel alongside the Mercury intermediate instruction stream so that FNLZR can update addresses, register assignments, and line mappings in lockstep when it rewrites Mercury IR into final SASS. nvlink emits 15 Mercury debug section variants through two dedicated classifier functions in the ptxas embedded backend, defers them during the merge phase via the 0x10000000 section flag, and validates them through the --self-check mechanism after SASS reconstitution.

Key Facts

How Mercury Debug Differs from SASS DWARF

Mercury debug information and standard SASS DWARF serve the same purpose -- mapping machine instructions back to source lines and variable locations -- but differ in four fundamental ways:

1. Address Granularity

Standard DWARF in a pre-sm100 cubin (e.g., sm89) uses final SASS instruction addresses. Every PC range in .debug_info, .debug_line, and .debug_loc refers to byte offsets within the .text section.

Mercury DWARF uses Mercury intermediate addresses. These addresses correspond to positions in the .nv.merc instruction stream, not the final SASS .text. Mercury instructions are a higher-level encoding (fewer instructions, wider semantics, no scheduling constraints) that FNLZR later expands, schedules, and register-allocates to produce SASS. Every address in every Mercury debug section will become stale after FNLZR processes the code.

2. Namespace Prefixing

All 15 debug sections carry the .nv.merc. prefix, placing them in a distinct namespace from the standard unprefixed debug sections:

This namespacing is not cosmetic. It allows both Mercury and SASS debug sections to coexist in the same ELF when the output format is capmerc (the default for sm100+). The Mercury sections are retained for potential JIT re-finalization by the CUDA driver, while the SASS sections are used by tools like cuda-gdb.

3. Section Flag Marking

Every Mercury section (debug and non-debug) carries the 0x10000000 flag in its sh_flags field. This flag has no standard ELF meaning (it falls within SHF_MASKPROC, 0xF0000000). The merge phase uses this flag as the sole discriminator to skip Mercury sections. Standard SASS debug sections do not carry this flag.

4. Relocation Architecture

Mercury debug sections reference Mercury-internal symbols through the Mercury symbol table (.nv.merc.symtab_shndx), not the standard cubin .symtab. The relocation processor (sub_1CF1690) handles both namespaces: it first tries the unprefixed name (e.g., .debug_frame), and if that fails and the 0x10000000 flag is set, falls through to the Mercury-prefixed name (e.g., .nv.merc.debug_frame). This dual-path design allows the same relocation function to process both standard and Mercury cubins.

Section Catalog

Standard DWARF Mirror Sections (11)

These sections replicate the standard DWARF debug section layout under the .nv.merc namespace. Each carries debug information at the Mercury instruction address granularity -- addresses that are not yet final and will change after FNLZR performs opex expansion, instruction scheduling, and register assignment.

NVIDIA-Specific Debug Sections (4)

These sections carry NVIDIA-proprietary debug data with no standard DWARF equivalent. They are classified by ELF_EmitSASSDebugSections (sub_1CED7C0).

The two register debug sections (.nv_debug_info_reg_sass and .nv_debug_info_reg_type) also appear at a separate string table location (0x241282C and 0x2412844), referenced by the register debug emitters at sub_181B160 and sub_181B270 in the embedded ptxas backend.

Section Detection: sub_1CED0E0

The function at 0x1CED0E0 (ELF_EmitDebugSections, 9,262 bytes, 373 decompiled lines) classifies whether an ELF section header describes a Mercury debug section. It returns 1 on match, 0 otherwise. The function is called from the ELF section builder during cubin generation.

Algorithm

The function takes two parameters: a pointer to the ELF context (a1, dereferenced for the string table base) and a pointer to a section header record (a2). It proceeds through a sequential chain of 15 string comparisons, one per Mercury debug section name:

int64_t ELF_EmitDebugSections(int64_t* elf_ctx, section_header_t* shdr)
{
    // For each candidate section name, check:
    //   1. Is the section type eligible? (sh_type check against CUDA section types)
    //   2. Does the section carry the Mercury flag? (sh_flags & 0x10000000)
    //   3. Does the resolved section name match the expected string?
    // Return 1 on first match, 0 if no match found.
}

The detection loop tests sections in this fixed order:

Section Type Guard

Before each string comparison, the function checks the section's sh_type field (at a2 + 4, i.e., *(uint32_t*)(a2 + 4)) against known CUDA section type ranges. The decompiled code reveals two type ranges that qualify as candidates:

// Range 1: CUDA processor-specific types 0x70000006 through 0x70000014
//   1879048198 <= sh_type <= 1879048212
(v4 - 1879048198) <= 0xE

// Range 2: Constant bank types 0x70000064 through 0x7000007E
//   1879048292 <= sh_type <= 1879048318
(v4 - 1879048292) <= 0x1A

Within Range 1, the constant 0x5D05 acts as a bitmask selecting specific section types. The expression (0x5D05 >> (sh_type - 6)) & 1 checks whether the low bits of sh_type (after subtracting 6 from the type code's offset within the range) correspond to an allowed type. In binary, 0x5D05 = 0101_1101_0000_0101, enabling types at bit positions 0, 2, 8, 10, 11, 12, 14. This maps to CUDA section types SHT_CUDA_CONSTANT (0x70000006), SHT_CUDA_GLOBAL_INIT (0x70000008), SHT_CUDA_UFT (0x7000000E), SHT_CUDA_UFT_ENTRY (0x70000011), SHT_CUDA_UDT (0x70000012), SHT_CUDA_UDT_ENTRY (0x70000014), and others.

An additional fast-path uses the constant 23813 (0x5D05) as a 64-bit bitmask through _bittest64. This is functionally identical to the shift-and-mask check but uses a single bit-test instruction: _bittest64(&23813, sh_type - 1879048198). The decompiled code alternates between these two representations depending on whether the compiler chose a shift or a BT instruction.

A section that passes the type guard must also have the 0x10000000 flag set in its sh_flags field (checked via *(uint64_t*)(a2 + 8) & 0x10000000) before the name resolution and string comparison proceed.

String Resolution

Section names are resolved through sub_448590, which takes the ELF string table base (from *a1) and the section header, returning a pointer to the null-terminated section name. The first comparison (.nv.merc.debug_abbrev) uses memcmp with a length of 22 bytes; subsequent comparisons use strcmp. The .nv.merc.nv_debug_ptx_txt comparison uses sub_44E3A0 (a starts-with predicate) rather than exact string matching, allowing suffixed variants (e.g., .nv.merc.nv_debug_ptx_txt.2).

SASS Debug Classifier: sub_1CED7C0

The companion function at 0x1CED7C0 (ELF_EmitSASSDebugSections, 6,757 bytes, 315 decompiled lines) is structurally parallel to sub_1CED0E0 but operates on the unprefixed debug section names. It classifies whether a section is a standard debug section (without the .nv.merc. prefix) that should be placed into the SASS debug output:

Note the deliberate asymmetry: sub_1CED0E0 tests .nv.merc.-prefixed names (Mercury container sections), while sub_1CED7C0 tests unprefixed names (standard debug sections). During ELF emission, the ptxas backend uses sub_1CED7C0 to identify which input debug sections should be re-emitted under the .nv.merc. namespace, and uses sub_1CED0E0 to identify existing Mercury debug sections (e.g., during relocation processing or validation).

The two classifiers do not check the 0x10000000 flag identically. sub_1CED0E0 requires the flag to be set (it is looking for Mercury sections). sub_1CED7C0 does not check the flag at all -- it operates on sections that may or may not be Mercury-marked, because it needs to identify standard debug sections for Mercury re-emission.

DWARF Emitter Debug Detection: sub_1672F50

The ptxas embedded backend contains a separate DWARF emitter at sub_1672F50 (22,076 bytes, 600 decompiled lines) that uses two prefix strings for debug section detection during code generation:

This function performs a prefix match against the section name to determine whether a given section requires DWARF emission. It is called during the ptxas compilation pipeline (before the ELF emission phase) to decide which sections receive debug content. The prefix strings at 0x226B814 and 0x226B81F are in a separate string table cluster from the Mercury debug strings, reflecting their use in the ptxas codegen rather than the nvlink linker.

Relocation Processing for Mercury Debug Sections

ELF_EmitRelocationTable (sub_1CF1690, 16,049 bytes, 545 decompiled lines) processes relocations for 7 of the 15 Mercury debug sections. The function implements a dual-lookup pattern: it first tests the unprefixed section name, and if that does not match and the 0x10000000 flag is set in sh_flags, it falls through to test the Mercury-prefixed name.

Dual-Lookup Pattern

For each of the 7 relocatable debug sections, the decompiled code follows this structure:

// First attempt: standard name
if (memcmp(section_name, ".debug_frame", 13) == 0) {
    if (!*(byte*)(ctx + 432))     // Mercury compatibility flag
        ctx->debug_frame_reloc = reloc_table;   // offset +72
}
// ... (fall through other sections) ...

// Second attempt: Mercury name (only if 0x10000000 flag set)
if ((sh_flags_byte11 & 0x10) != 0) {
    if (strcmp(section_name, ".nv.merc.debug_frame") == 0) {
        if (*(byte*)(ctx + 432))
            ctx->debug_frame_reloc = reloc_table;
    }
}

The byte at ctx + 432 serves as a Mercury compatibility discriminator. When it is 0, the standard unprefixed path stores the relocation table pointer; when it is non-zero, only the Mercury-prefixed path succeeds. This ensures that relocation table pointers are stored exactly once regardless of whether the input is a standard or Mercury cubin.

Relocation Table Assignment Offsets

Each matched section stores its relocation table pointer at a specific offset within the FNLZR context structure:

Sections Without Relocations (8)

The remaining 8 sections do not carry relocations:

Mercury Section Flag: 0x10000000

All Mercury sections (not just debug) are tagged with bit 28 (0x10000000) in their ELF section header sh_flags field. This is a custom NVIDIA flag within the processor-specific range SHF_MASKPROC (0xF0000000). It has no standard ELF equivalent.

The flag serves as the primary discriminator during the merge phase. When merge_elf (sub_45E7D0) processes input cubins for a Mercury-compatible target, it tests each section's flags:

if (is_mercury_compatible && (section_flags & 0x10000000) != 0) {
    // verbose: "skip mercury section %i"
    continue;
}

The verbose message "skip mercury section %i\n" is at 0x1D3BCB7. The string reference appears in two locations within sub_45E7D0: at 0x460D4B (first section iteration, line 1583 of the decompiled file) and at 0x461549 (second section iteration, line 1711).

The Mercury compatibility condition is a conjunction of two flags:

1. The output context flag at ctx + 48 (set when the output target is sm100+)
2. A flag derived from the input ELF header (set when the input cubin was compiled for a Mercury target)

Both must be true for the skip to activate. If either is false (e.g., linking legacy SASS cubins with Mercury cubins), the Mercury sections are treated as opaque data and merged normally.

Why Skip During Merge?

Mercury debug sections are skipped during the merge phase because their content will be entirely rewritten by FNLZR:

1. Address instability: Mercury instruction addresses change after opex expansion (Mercury opcode to SASS instruction expansion) and scheduling. All debug sections referencing Mercury addresses become stale.
2. Symbol namespace isolation: Mercury relocations reference Mercury-internal symbols, not the output ELF symbol table. Merging them would require unnecessary symbol table translation.
3. Wholesale replacement: FNLZR replaces Mercury debug sections with SASS-level equivalents. Merging them into the output ELF would be wasted work that FNLZR would immediately discard.

The skipped sections are not lost. They remain in the per-input cubin images held in memory. The FNLZR post-link transformation operates on the complete in-memory ELF and has access to these sections for code rewriting and debug info regeneration.

Debug Section Merging During Mercury Linking

Mercury linking introduces a distinctive merge strategy for debug sections that differs from the traditional SASS linking approach.

Traditional SASS Debug Merge (Pre-sm100)

For pre-Mercury targets, debug sections from multiple input cubins are concatenated and their internal offsets are adjusted through relocation processing. .debug_info sections from different compilation units are appended in order, .debug_abbrev tables are merged with code deduplication, and .debug_line programs are concatenated with adjusted file indices. This is standard DWARF link-time processing.

Mercury Debug Merge

For Mercury targets, the merge phase skips all 15 Mercury debug sections entirely. The per-input cubin Mercury debug sections are preserved in-memory but never combined into the output ELF. Instead:

1. Per-kernel preservation: Each input cubin retains its own .nv.merc.debug_* sections in memory.
2. FNLZR per-kernel processing: When FNLZR processes each kernel (through the per-kernel iteration at sub_471700, called from sub_4748F0 line 1247), it reads the Mercury debug sections from the preserved input image.
3. Debug regeneration: FNLZR's compilation pipeline regenerates all debug information from scratch at the SASS level. The Mercury-address debug data is used only as input to the address remapping; the output debug sections contain final SASS addresses.
4. Final emission: The output ELF writer (sub_1CF3720 for complete objects, sub_1CF7F30 for relocatable) emits both standard .debug_* sections (for tool consumption) and, if the output is capmerc format, .nv.merc.debug_* sections (for JIT re-finalization).

Non-debug Mercury Sections in the Merge

Two Mercury structural sections are also skipped during merge:

• .nv.merc.rela (Mercury relocations, string at 0x2458D00)
• .nv.merc.symtab_shndx (Mercury extended symbol indices, string at 0x2458490)

The .nv.merc container section (the Mercury code itself, string at 0x2458305) is likewise skipped.

FNLZR Debug Serialization: Phase 7

Phase 7 of the FNLZR pipeline (lines 1294--1372 of sub_4748F0 at 0x4748F0) handles post-compilation serialization of debug information. It is embedded within Phase 6 of the 10-phase FNLZR pipeline and operates on the compilation output structures built by the ptxas backend.

Phase 7a: .debug_line Serialization

if (debug_line_input) {        // v357 = v419[10]
    sub_477480(debug_out, 0);  // Build debug line table (mode=0)
    sub_4783C0(debug_out, 0);  // Serialize debug line program (mode=0)
    result = sub_477510(debug_out, 0);  // Extract serialized section
    debug_line_input[1] = *(qword*)(result + 8);       // data pointer
    *(dword*)(debug_line_input + 16) = *(dword*)(result + 16) + 1;  // size (+1 for NUL)
}

sub_477480 (at 0x477480, 55 lines) iterates over the compilation units stored in the debug output structure and calls sub_464D00 to sort/finalize each unit's line table entries. The mode parameter (0 for .debug_line, 1 for .debug_frame) selects which slot of the debug output structure to process: mode 0 reads from offsets +16 / +24, mode 1 from offsets +40 / +48.

sub_4783C0 (at 0x4783C0, ~200 lines) is the actual DWARF line number program serializer. It walks the sorted line table entries and emits the standard DWARF line number program opcodes (special opcodes, extended opcodes, DW_LNS_copy, etc.) into a buffer. The output is a complete .debug_line section ready for inclusion in the output ELF.

sub_477510 (at 0x477510, 14 lines) is a trivial accessor that returns a pointer to the serialized data. Mode 0 returns offset +56 of the debug output structure; mode 1 returns offset +80.

The +1 adjustment on the serialized size accounts for the NUL terminator byte that the serializer does not include in its reported size.

Phase 7b: .debug_frame Serialization

if (debug_frame_input) {        // v358 = v419[11]
    sub_477480(debug_out, 1);   // Build debug frame table (mode=1)
    sub_4783C0(debug_out, 1);   // Serialize debug frame program (mode=1)
    result = sub_477510(debug_out, 1);
    debug_frame_input[1] = *(qword*)(result + 8);
    *(dword*)(debug_frame_input + 16) = *(dword*)(result + 16) + 1;
}

The .debug_frame path is structurally identical to .debug_line, differing only in the mode parameter. The same three functions are called with mode=1, accessing the frame-specific slots in the debug output structure.

Phase 7c: Debug Address Remapping

if (v419[14] && v419[14][4]) {     // relocation entries exist
    sub_4826F0(&bst_root, debug_out, 0);  // Build BST from address map
    for (idx = 0; idx < section_count; idx++) {
        entry = get_entry(v419[14][4], idx);
        if (entry->reloc_type == 0x10008) {     // R_CUDA_ABS32_HI_20
            sym_idx  = entry->sym_index;        // at entry + 28
            symtab   = find_section(elf_data, ".symtab");
            sym_name = resolve_symbol(elf_data, symtab, sym_idx);
            if (strncmp(sym_name, ".debug_line", 12) == 0) {
                // Look up original offset in BST and patch entry
                original_offset = *(dword*)(entry + 8);
                node = bst_root;
                while (node) {
                    if (original_offset < node->key)
                        node = node->left;
                    else if (original_offset > node->key)
                        node = node->right;
                    else {
                        *(qword*)(entry + 8) = node->value;
                        break;
                    }
                }
            }
        }
    }
    sub_4747E0(&bst_root);   // destroy BST
    sub_474760(&bst_aux);    // destroy auxiliary data
}

sub_4826F0 (at 0x4826F0, ~90 lines) builds a binary search tree (BST) that maps original Mercury-address .debug_line section offsets to their new positions in the recompiled output. The relocation type 0x10008 (65,544 decimal) is R_CUDA_ABS32_HI_20 -- the high 20 bits of a 32-bit absolute relocation used for debug section cross-references. The BST lookup patches each relocation entry's offset to reflect the SASS-level address.

How -g Affects Mercury Debug Output

The -g flag (--device-debug) propagates through the pipeline and controls Mercury debug section generation at multiple levels:

Flag Propagation

Section Population by Debug Level

The --generate-line-info mode populates only the two line-mapping sections (.debug_line and .nv_debug_line_sass), which is sufficient for source-level profiling tools like Nsight Compute but not for interactive debugging. The -g mode populates all 15 sections for full cuda-gdb support.

The --suppress-debug-info Override

When --suppress-debug-info is present alongside -g, byte_2A5F310 is cleared to 0 before any compilation begins (sub_427AE0 line 1084). This is a pre-generation suppression: the embedded ptxas never receives the --device-debug flag, so no debug sections are generated at all. The Mercury debug classifier functions still exist in the output path but never encounter Mercury debug sections because none were emitted.

Architecture-Derived Flags

Three architecture-derived flags control Mercury debug emission:

The five sections unlocked by Mercury mode that are absent in SASS-only mode (sm90--sm99) are .nv.merc.debug_aranges, .nv.merc.debug_ranges, .nv.merc.debug_macinfo, .nv.merc.debug_pubnames, and .nv.merc.debug_pubtypes.

Self-Check Validation

The --self-check CLI flag triggers a round-trip validation where the linker reconstitutes SASS from the capmerc binary and compares it against expected output. Debug sections are one of three independently validated categories:

Self-Check Debug Verification Algorithm

The self-check (Phase 9 of FNLZR, lines 1493--1729 of sub_4748F0) performs a recursive invocation of the FNLZR engine itself. The reconstituted SASS is produced by calling sub_4748F0 again with the output from Phase 6 as input. The debug section comparison proceeds in two stages:

Stage 1: Section count match (line 1639). The number of sections in v419[60] (the original debug section list) must equal the number of sections in the reconstituted output's debug section list (at v348 + 24). If the counts differ, error code 19 is set.

Stage 2: Per-section content match (lines 1641--1677). For each section in the original list:

1. The section name is extracted and the .nv.merc. prefix is stripped (offset +8) if present.
2. The same stripping is applied to the reconstituted section.
3. The stripped names are compared with strcmp. If they match, the section sizes and content are compared byte-by-byte.
4. If any comparison fails, error code 19 is set.

The prefix stripping uses sub_44E3A0 (starts-with predicate) with the 9-byte string ".nv.merc." at 0x1D40605. The stripping advances the pointer by 8 bytes (not 9), producing a result that retains the leading dot (e.g., ".nv.merc.debug_info" + 8 = ".debug_info"). This is correct because the .nv.merc. prefix is 9 characters including the trailing dot, but the stripped name must retain its own leading dot.

Stage 3: Relocation section match (lines 1679--1729). A parallel comparison loop runs for the relocation sections stored in v419[61], using identical prefix stripping and byte comparison. The same error codes apply.

When any self-check fails, the detailed error message is emitted:

Failure of '%s' section in self-check for capsule mercury.
See the Jira confluence page 'MERCSW-125' for more information
that includes some debugging steps.

The %s is the section name that failed comparison. The string is at 0x1F44288.

Self-Check Error Codes

The self-check produces three distinct error codes:

FNLZR Prefix Matching

During finalization, sub_4748F0 (nvlink_link_and_finalize_entry, 48,730 bytes) iterates over section names using the prefix string ".nv.merc." (9 bytes, at 0x1D40605) as a discriminator. The matching function sub_44E3A0 performs a starts-with check. When a section name matches:

char* section_name = get_section_name(section);
if (starts_with(".nv.merc.", section_name)) {
    // Strip the ".nv.merc." prefix (advance pointer by 8 bytes)
    // to recover the original section name, e.g.:
    //   ".nv.merc.debug_info" -> ".debug_info" (offset +8, not +9)
    section_name += 8;
}

The prefix strip uses offset 8 (not 9), which means the result retains the leading dot: ".nv.merc.debug_info" + 8 = ".debug_info". This is consistent with the standard DWARF section naming convention and allows FNLZR to dispatch the stripped name through the same debug section classification paths used for standard cubins.

The FNLZR uses this stripped name in 4 code paths within sub_4748F0:

Emission Call Chain

The complete emission path from the ptxas backend to the final cubin:

ELF_WriteCompleteObject (sub_1CF3720, 99 KB)
  |
  +-- ELF_BuildSectionTable (sub_1CEE030, 26 KB)
  |     |
  |     +-- ELF_EmitConstantSection (sub_1CEC7E0)
  |     +-- ELF_EmitReservedSmem (sub_1CECBB0)
  |     +-- ELF_EmitDebugSections (sub_1CED0E0) --> classify .nv.merc.debug_*
  |     +-- ELF_EmitSASSDebugSections (sub_1CED7C0) --> classify .debug_* for Mercury re-emission
  |     +-- ELF_EmitSpecialSections (sub_1CEDD50) --> handles .nv_debug_info_reg_{sass,type}
  |     |     xrefs: sub_1CEDF2B (.nv_debug_info_reg_sass), sub_1CEDF7A (.nv_debug_info_reg_type)
  |
  +-- ELF_ProcessRelocations (sub_1CEF5B0) --> .nv.merc.symtab_shndx
  +-- ELF_EmitSymbolTable (sub_1CF07A0)
  +-- ELF_EmitRelocationTable (sub_1CF1690) --> relocations for 7 Mercury debug sections
  +-- ELF_EmitSectionHeaders (sub_1CF2100) --> .nv.merc.rela
  +-- ELF_EmitProgramHeaders (sub_1CF72E0)

Lifecycle Through the Pipeline

1. ptxas backend (embedded in nvlink): Compiles PTX to Mercury IR. The ELF object emitter creates all 15 debug sections under the .nv.merc namespace. Each section's sh_flags includes 0x10000000. Seven of the 15 sections receive relocation entries through sub_1CF1690. The DWARF emitter (sub_1672F50) detects debug sections using the .nv_debug_ and .debug_ prefix strings at 0x226B814 and 0x226B81F. Timing information is tracked via the "DebugInfo-time" diagnostic at 0x1EED040 and peak memory via "PeakDebugInfoMemoryUsage" at 0x1EED160.

2. nvlink merge phase (sub_45E7D0): When linking for a Mercury target, sections with sh_flags & 0x10000000 are skipped. They are not merged into the output ELF. Verbose mode prints "skip mercury section %i" for each. Two independent code paths check the flag (lines 1583 and 1711 of the decompiled merge function), corresponding to the two iteration passes over input sections.

3. nvlink output phase: The complete pre-FNLZR image is serialized to an in-memory buffer. For --extract debug workflows, this intermediate image may be written to a side file.

4. FNLZR post-link transformation (sub_4748F0 -> sub_471700): The finalizer reads the Mercury container, strips the ".nv.merc." prefix from section names (offset +8), and dispatches each debug section through the finalization rewrite. Phase 7 of the FNLZR serializes .debug_line and .debug_frame through three helper functions (sub_477480, sub_4783C0, sub_477510), then remaps .debug_line relocation offsets through a BST built by sub_4826F0. The BST maps Mercury-address offsets to SASS-address offsets, updating relocation type 0x10008 (R_CUDA_ABS32_HI_20) entries that reference .debug_line symbols.

5. Self-check (optional, --self-check): Phase 9 recursively invokes sub_4748F0 on the finalized output, strips .nv.merc. prefixes from both the original and reconstituted section names, and compares section contents byte-by-byte. Debug sections are checked in a dedicated loop (lines 1641--1677) with error code 19 on mismatch. Failure triggers the "Self check for capsule mercury debug section failed" error with a reference to internal Jira MERCSW-125.

6. Final output: The rewritten cubin contains SASS .text instead of .nv.merc code. If the output format is capmerc (default for sm100+), the Mercury container is preserved alongside SASS for JIT re-finalization by the CUDA driver. The capmerc output includes both .nv.merc.debug_* sections (for driver JIT) and standard .debug_* sections (for tools).

Note on Section Name Encoding

The Mercury debug section names (.nv.merc.debug_*) are straightforward namespace-prefixed strings. There is no ROT13 encoding, Caesar cipher, or other obfuscation applied to Mercury debug section names in nvlink v13.0.88. The only obfuscation mechanism in the binary relates to PTX source text (strings "obfuscated ptx" at 0x1EE9918 and "Error reading obfuscated PTX file" at 0x1F42CF8), which is unrelated to debug section naming. The .nv.merc. prefix is a plain namespace identifier, not an encoded form.

Function Map

Cross-References

nvlink Wiki

• FNLZR -- the post-link finalizer that consumes Mercury debug sections; Phase 7 (debug serialization) and Phase 9 (self-check) are the primary debug processing phases
• Mercury ELF Sections -- complete catalog of all 19 .nv.merc.* sections including non-debug structural sections
• Mercury Overview -- what Mercury is and why it exists
• Capsule Mercury Format -- self-check mechanism and capmerc pipeline
• DWARF Processing -- core DWARF parser that feeds Mercury debug emission; processes .debug_info through classifier at sub_12D4370
• NVIDIA Debug Extensions -- non-Mercury .nv_debug_* section catalog; the 4 NVIDIA-specific Mercury sections mirror these
• Line Table Merging -- how .debug_line / .nv_debug_line_sass are built during LTO; Phase 7a of FNLZR re-serializes these
• Debug Options -- debug level flags and FNLZR debug section control; documents byte_2A5F310, byte_2A5F222, and the -g / --generate-line-info / --suppress-debug-info interactions
• Merge Phase -- where Mercury sections are skipped during linking, gated by the 0x10000000 flag
• Section Merging -- general section merge mechanics and CUDA type catalog
• NVIDIA Section Types -- section type constants and the SHF_CUDA_MERCURY flag (0x10000000)

Sibling Wikis

• ptxas: Debug Info -- ptxas generates both standard and Mercury-prefixed debug sections; its Mercury debug classifier at sub_1C98C60 identifies .nv.merc.debug_* sections, and the SASS debug classifier at sub_1C99340 handles unprefixed .debug_* sections
• cicc: Debug Info Pipeline -- cicc's debug metadata generation is upstream of Mercury section creation; the debug info mode (-g vs -generate-line-info) propagated through nvlink's LTO pipeline determines which Mercury debug sections are populated

Confidence Assessment