R_MERCURY Relocations

nvlink defines 65 Mercury-specific ELF relocation types for the capsule Mercury (capmerc) binary format, used on sm100+ architectures (Blackwell and later). These types are stored in .rela.* sections of capmerc ELF files and are consumed by the same relocation application engine that handles R_CUDA types, but through a separate descriptor table. Each R_MERCURY type in the ELF is encoded as the table index plus 0x10000 -- the relocation engine subtracts this offset at dispatch time to index into the Mercury-specific descriptor table.

Mercury relocations are structurally simpler than their R_CUDA counterparts. Where R_CUDA has 119 types covering six generations of SASS instruction encoding (each with different bit-field positions for the same logical operation), R_MERCURY has 65 types that target a single 128-bit instruction format. The R_MERCURY set eliminates the per-bit-position variants (R_CUDA_ABS32_20, R_CUDA_ABS32_23, R_CUDA_ABS32_26, R_CUDA_ABS32_32) in favor of position-independent types (R_MERCURY_ABS32) -- the bit-field position is encoded in the 64-byte descriptor rather than in the type name.

Key Facts

ELF Type Encoding and Dispatch

When the linker loads a relocation entry from a capmerc ELF file, the r_info type field contains the Mercury type index plus 0x10000. The dispatch logic in the relocation phase function (sub_469D60) detects this offset and routes to the Mercury descriptor table. The code from the decompiled sub_469D60 at lines 188--215 shows the exact branching:

// sub_469D60 at 0x469D60 -- relocation phase dispatcher
// v2 = linker context, v5 = rela entry (16-byte __m128i), v9 = reloc type

v7 = 1;
v8 = rela_entry->type_and_sym;          // r_info from Elf64_Rela
if (*(byte*)(context + 7) != 0x41)       // check ELF class byte at offset +7
    v7 = 0x80000000;                     // non-Mercury flag
v9 = rela_entry->type_and_sym;

if ((v7 & *(uint32*)(context + 48)) != 0) {  // Mercury path
    if ((uint32_t)v8 != 0) {
        if ((uint32_t)v8 <= 0x10000) {
            fatal("unexpected reloc");        // Mercury types must be > 0x10000
        }
        descriptor_table = &off_1D3CBE0;      // Mercury descriptor table
        type_index = v9 - 0x10000;            // subtract offset to get raw index
    } else {
        descriptor_table = &off_1D3CBE0;
        type_index = 0;                       // R_MERCURY_NONE
    }
} else {                                      // CUDA path
    type_index = rela_entry->type;
    descriptor_table = &off_1D3DBE0;          // CUDA descriptor table
}

The 0x10000 namespace separation ensures that R_MERCURY and R_CUDA type numbers never collide. A raw ELF type value of 0x10000 maps to Mercury index 0 (R_MERCURY_NONE); 0x10001 maps to index 1 (R_MERCURY_G64); and so on through 0x10040 for index 64 (R_MERCURY_NONE_LAST).

The ELF class byte at offset +7 of the linker context distinguishes Mercury from CUDA. The value 0x41 (ASCII 'A') indicates a Mercury ELF. When this byte is 0x41, the dispatcher sets the Mercury flag to 1; otherwise it sets 0x80000000 (the CUDA/traditional cubin flag). The AND with the e_flags word at context offset +48 determines which path is taken.

Relocation Record Builder: sub_469B50

Before the relocation engine runs, the record builder at sub_469B50 creates linked-list entries for each relocation. This function also performs the table selection and index normalization:

// sub_469B50 at 0x469B50 -- builds relocation records
v6 = 0x80000000;
if (*(byte*)(context + 7) == 0x41)       // Mercury ELF?
    v6 = 1;

// Validate the relocation type against the target architecture
result = sub_42F6C0(reloc_type, arch_class, (v6 & e_flags) != 0, ...);
if (!result) return;

// Select descriptor table for action-type checking
if ((v6 & e_flags) != 0) {               // Mercury path
    normalized_index = reloc_type - 0x10000;
    table = &off_1D3CBE0;
    if (normalized_index <= 0x3F) {        // index < 64
        // Check if action type indicates a special reloc (codes 12-15)
        if ((uint32_t)(table[8 * normalized_index + 2].hi - 12) <= 3)
            sub_44C010(context, section_idx);   // mark section for special handling
    }
} else {                                  // CUDA path
    normalized_index = reloc_type;
    table = &off_1D3DBE0;
    if (normalized_index <= 0x73) {        // index < 116
        // Same action-type check for CUDA
        ...
    }
}

The action-type range check (action_type - 12) <= 3 catches types with action codes 12 through 15, which correspond to special relocation operations that require the target section to be marked for deferred processing.

Naming Convention

R_MERCURY type names follow a simpler pattern than R_CUDA:

R_MERCURY_<category>[<bits>][_<byte_offset>]

Because Mercury targets a single 128-bit instruction format (not the variable 64/128-bit encodings of previous SASS generations), there is no need for per-bit-position suffixes. The components are:

• Category: the semantic class of the relocation (ABS, G, PROG_REL, FUNC_DESC, UNIFIED, TEX, SAMP, SURF)
• Bits: the width of the relocated value (8, 16, 32, 64)
• Byte offset: for byte-level variants, the bit offset within the 64-bit word (_0, _8, _16, _24, _32, _40, _48, _56)
• HI/LO: for split relocations, which half of a 32-bit value is patched

Complete Type Catalog

Sentinel Types

R_MERCURY_NONE at index 0 serves the same purpose as R_CUDA_NONE: it is a no-op relocation used for entries that have been eliminated by dead code removal or relocation merging. The application engine returns immediately when it encounters a descriptor with all-zero action types. R_MERCURY_NONE_LAST at index 64 is a bounds sentinel -- the validation function rejects any type index >= 65.

Global Address Relocation

R_MERCURY_G64 is the primary relocation for global memory address references. It computes S + A (symbol value plus addend) and writes the full 64-bit result. Used for references to symbols in .nv.global and similar global data sections. This is the Mercury equivalent of R_CUDA_G64.

Absolute Data Relocations

These relocations apply to data sections and instruction immediate fields using absolute addressing. The engine computes S + A and writes the result (or a 16-bit portion of it for _LO/_HI variants).

The ABS32_LO / ABS32_HI pair is used when a 32-bit absolute address must be split across two instruction immediates. One instruction loads the low 16 bits, the other loads the high 16 bits. The linker resolves both from the same symbol.

Unlike R_CUDA, which has separate types for each bit-position within the instruction word (R_CUDA_ABS32_20, R_CUDA_ABS32_23, R_CUDA_ABS32_26, R_CUDA_ABS32_32), the Mercury types are position-independent -- the bit-field offset is stored in the 64-byte descriptor entry.

PC-Relative Relocations

PC-relative relocations compute (S + A) - PC, where PC is the address of the instruction being patched. These are used for branch instructions (BRA, CALL, BRX) in Mercury's 128-bit instruction format.

The 64-bit variant (PROG_REL64) supports the full address space. The 32-bit variant limits branch distances to +/- 2 GB, sufficient for all practical kernel sizes. The _LO/_HI split variants handle cases where the PC-relative offset must be encoded in two separate instruction fields.

In the application engine, PC-relative relocations use action type 0x10 (pc_rel), which computes (int32_t)(S + A) - section_offset. The relocation phase function (sub_469D60) validates at line 409--410 that PC-relative branch targets reside in the same section:

if (descriptor[5] == 16 && rela_entry.section_idx != target_section_idx)
    fatal("PC relative branch address should be in the same section");

Texture, Sampler, and Surface Relocations

These relocations resolve bindable resource references -- texture, sampler, and surface objects -- by patching the merged header table index into instruction fields. During linking, individual per-module header tables are merged into a single global table; these relocations update the instruction operands to reference the correct entry in the merged table.

These are direct equivalents of R_CUDA_TEX_HEADER_INDEX, R_CUDA_SAMP_HEADER_INDEX, and R_CUDA_SURF_HEADER_INDEX. Mercury drops the SLOT, HW_DESC, and HW_SW_DESC variants that exist in R_CUDA, consolidating texture resource binding into the header index mechanism alone.

Clear Relocation

Writes zeros to a 64-bit field. Used to clear placeholder entries in merged data sections or nullify unused instruction fields after linking. Uses action types 0x13 or 0x14 (clear), which simply AND-zero the target bit-field without computing any symbol value. Equivalent to R_CUDA_UNUSED_CLEAR64.

Function Descriptor Relocation

Resolves a reference to a function descriptor entry. Function descriptors are used for indirect calls, virtual function tables, and device-side function pointers. The relocation writes the 64-bit address of the descriptor entry.

Byte-Level Relocations (R_MERCURY_8_*)

Byte-granularity relocations that patch a single 8-bit byte at a specific offset within a 64-bit data word. The eight types cover all byte positions within a 64-bit value. These are used for patching descriptor tables, attribute sections, and other data structures where individual bytes must be resolved separately.

Direct equivalents of R_CUDA_8_0 through R_CUDA_8_56.

Global Byte-Level Relocations (R_MERCURY_G8_*)

Byte-granularity relocations for global memory addresses. These are the byte-level counterparts of R_MERCURY_G64 -- instead of writing a full 64-bit global address, they write a single byte of the address at a specific position. Used when a global address must be assembled byte-by-byte in a data structure.

Direct equivalents of R_CUDA_G8_0 through R_CUDA_G8_56.

Function Descriptor Byte-Level Relocations (R_MERCURY_FUNC_DESC_8_*)

Byte-level relocations for function descriptor addresses in data sections. These patch individual bytes of a 64-bit function descriptor reference, mirroring the R_MERCURY_FUNC_DESC_64 / byte-level split pattern used by the other relocation families.

Direct equivalents of R_CUDA_FUNC_DESC_8_0 through R_CUDA_FUNC_DESC_8_56.

Absolute PC-Relative Relocations

These are hybrid relocations that combine absolute and PC-relative semantics. The computation is |S + A - PC| or a variant that uses the absolute value of the PC-relative offset, used in instruction encodings that require an unsigned distance rather than a signed offset.

The _LO/_HI split variants (indices 40--41) appear earlier in the table than the full-width variants (indices 60--61), suggesting they were added in an earlier revision and the full-width types were appended later.

No direct R_CUDA equivalent exists for these types. They appear to be Mercury-specific additions for the 128-bit instruction format's distance-based addressing modes.

PC-Relative Byte-Level Relocations (R_MERCURY_PROG_REL8_*)

Byte-level PC-relative relocations. These compute (S + A) - PC and then extract a single byte at the specified offset from the result. Used for data structures that assemble PC-relative offsets byte-by-byte.

No direct R_CUDA equivalent exists. These are Mercury-specific additions for use in data tables (jump tables, exception tables) where PC-relative distances are stored in byte-addressable format.

Unified Table Relocations (R_MERCURY_UNIFIED_*)

Unified table relocations handle references to the Unified Descriptor Table (UDT) and Unified Function Table (UFT). These tables are used for CUDA Dynamic Parallelism and indirect function calls.

R_MERCURY_UNIFIED (index 50) is a generic marker type, not a data-patching relocation. During the relocation phase, unified relocations targeting synthetic symbols (__UFT_OFFSET, __UDT_OFFSET, __UFT_CANONICAL, __UDT_CANONICAL, __UDT, __UFT, __UFT_END, __UDT_END) are resolved to type 0 (no-op) because the unified table manager computes final offsets before the relocation engine runs. The code in sub_469D60 lines 377--395 explicitly checks for the __UFT_OFFSET symbol by string comparison and emits a debug trace when matched:

// Check if symbol name is "__UFT_OFFSET" (13-byte comparison)
if (strncmp(symbol_name, "__UFT_OFFSET", 13) == 0) {
    if (debug_flags & 4)
        fwrite("ignore reloc on UFT_OFFSET\n", 1, 0x1B, stderr);
    rela_entry.type = 0;   // convert to R_MERCURY_NONE
    ...
}

The UNIFIED32_LO and UNIFIED32_HI types (indices 62--63) appear after the ABS_PROG_REL types in the table rather than adjacent to the other unified types (50--59). This suggests they were added in a later revision.

Two additional trailing-space variants ("R_MERCURY_UNIFIED_8_0 " and "R_MERCURY_UNIFIED_8_8 ") appear at separate string addresses (0x1D3CB71 and 0x1D3CB88) in the Mercury descriptor table region. These are duplicate name strings used by the descriptor table entries themselves, distinct from the primary name table entries (which lack the trailing space). The trailing space is a formatting artifact in the binary's .rodata, not a distinct relocation type.

The Sub-Byte Relocation Mechanism

Mercury introduces a sub-byte relocation mechanism unique to GPU instruction patching. The byte-level relocation families (R_MERCURY_8_*, R_MERCURY_G8_*, R_MERCURY_FUNC_DESC_8_*, R_MERCURY_PROG_REL8_*, R_MERCURY_UNIFIED_8_*) each provide eight variants covering every byte position within a 64-bit word. The mechanism works as follows:

How Sub-Byte Patching Works

1. Full address computation: The engine first computes the full relocation value (S + A for absolute, (S + A) - PC for PC-relative).

2. Byte extraction: The descriptor's action type encodes which byte of the 64-bit result to extract. The action types 0x16--0x1D and 0x2F--0x36 (masked_shift operations) use paired SSE constant vectors loaded from xmmword_1D3F8E0--xmmword_1D3F930. These contain 64-bit masks and shift counts indexed by (action_type - 22):

// sub_468760, case 0x16..0x1D / 0x2F..0x36 (masked_shift)
int idx = action_type - 22;
uint64_t mask  = mask_table[idx];   // from xmmword_1D3F920/xmmword_1D3F930
uint64_t shift = shift_table[idx];  // from xmmword_1D3F8E0..xmmword_1D3F910
value = (value & mask) >> shift;

3. Bit-field insertion: The extracted byte is written into the target using the descriptor's bit_offset and bit_width fields, via the sub_4685B0 helper.

Multi-Word Boundary Handling

Both the extraction (sub_468670) and write (sub_4685B0) helpers handle bit-fields that span 64-bit word boundaries -- a common situation with 128-bit Mercury instructions. The extraction function is recursive:

// sub_468670 -- bitfield_extract (simplified)
int64_t bitfield_extract(uint64_t* words, int bit_offset, int bit_width) {
    if (bit_offset >= 64) {
        words += bit_offset / 64;
        bit_offset %= 64;
    }
    int end_bit = bit_offset + bit_width;
    if (end_bit <= 64)
        return *words << (64 - end_bit) >> (64 - bit_width);

    // Recursive split: low part from this word, high part from next
    int64_t low  = bitfield_extract(words, bit_offset, 64 - bit_offset);
    int64_t high = words[1] << (128 - end_bit) >> (64 - (end_bit - 64));
    return low | (high << (64 - bit_offset));
}

The write function (sub_4685B0) similarly handles multi-word spans with an iterative loop that processes one 64-bit word at a time, shifting the value right after each partial write.

Why Sub-Byte Relocations Exist

The 8-bit relocations serve data sections where 64-bit addresses are stored in structures with byte-aligned fields. Rather than requiring the compiler to emit aligned 64-bit relocations, the linker can patch individual bytes. This is particularly useful for:

• Descriptor tables: Hardware descriptor entries that pack multiple fields into bytes
• Jump tables: Array entries stored as byte-packed offsets
• Constant buffer initialization: Per-byte patching of constant bank data
• Debug section data: DWARF entries with byte-level address references

The PC-relative byte-level family (R_MERCURY_PROG_REL8_*) is unique to Mercury and has no R_CUDA counterpart. It enables byte-by-byte assembly of PC-relative offsets in data tables, which previous SASS generations did not support.

Descriptor Table Structure

The Mercury descriptor table at off_1D3CBE0 has the same 64-byte-per-entry format as the CUDA table at off_1D3DBE0. Each entry encodes up to three patching actions:

Entry (64 bytes):
  +0   Header (12 bytes)
       +0   uint32_t  field_0;      // extraction spec for --preserve-relocs
       +4   uint32_t  field_1;      // extraction spec
       +8   uint32_t  field_2;      // extraction spec / action count hint
  +12  Action 0 (16 bytes)
       +12  uint32_t  bit_offset;   // start bit in instruction/data word
       +16  uint32_t  bit_width;    // number of bits to patch
       +20  uint32_t  action_type;  // operation code (see table below)
       +24  uint32_t  reserved;     // flags / padding
  +28  Action 1 (16 bytes)
       +28  uint32_t  bit_offset;
       +32  uint32_t  bit_width;
       +36  uint32_t  action_type;
       +40  uint32_t  reserved;
  +44  Action 2 (16 bytes)
       +44  uint32_t  bit_offset;
       +48  uint32_t  bit_width;
       +52  uint32_t  action_type;
       +56  uint32_t  reserved;
  +60  Sentinel (4 bytes, marks end of action array)

The application engine (sub_468760) indexes into the table and sets up its action pointer and sentinel:

descriptor_base = table + (type_index << 6);  // type_index * 64
action_ptr = descriptor_base + 12;             // first action at byte +12
end_ptr    = descriptor_base + 60;             // sentinel at byte +60

Action Types Used by Mercury Descriptors

The action types are identical between CUDA and Mercury -- the engine is shared. Mercury descriptors use the following subset:

Mercury does not use action types 0x08 (abs_size), 0x0A (sec_type_lo), or 0x0B (sec_type_hi), which are R_CUDA-specific operations for section-type patching and symbol-size computation.

Difference from R_CUDA Descriptors

Although the table format is identical, the descriptor contents differ from R_CUDA because Mercury's 128-bit instruction words have different field layouts. A relocation that places a 32-bit absolute address at bit position 20 in a 64-bit CUDA instruction will place it at a different bit position in a 128-bit Mercury instruction -- and this difference is encoded in the descriptor's bit_offset field, not in the type name.

The shared application engine sub_468760 is type-agnostic: it simply reads the descriptor, executes the action sequence, and patches the bit fields. The distinction between CUDA and Mercury is entirely in which descriptor table is selected at dispatch time.

Mercury Relocations and FNLZR Finalization

Mercury relocations interact with the FNLZR (Finalizer) subsystem at two critical points in the pipeline.

Pre-Link Mode: Relocation Passthrough

In pre-link mode (sub_4275C0 with a5 == 0), FNLZR processes individual cubins before they enter the merge phase. Mercury relocations at this stage are stored in .nv.merc.rela sections and reference the Mercury-private symbol table. The pre-link pass:

1. Validates the ELF class byte is 0x41 (Mercury)
2. Checks that finalization has not already been applied ((flags >> 2) & 1 must be 0)
3. Passes the cubin through the sub_4748F0 engine, which may rewrite relocations during opex expansion
4. Outputs a transformed cubin with potentially modified relocation entries

Post-Link Mode: Final Application

In post-link mode (sub_4275C0 with a5 == 1), FNLZR runs after the merge phase has applied all standard relocations. The post-link path:

1. Confirms the SASS-present or capmerc bit is set in e_flags
2. Invokes sub_4748F0 for the capmerc-to-SASS transformation
3. The engine re-resolves any remaining Mercury relocations against the final symbol table
4. Outputs the final SASS binary with all relocations fully applied

The FNLZR diagnostic output shows the relocation interaction:

FNLZR: Input ELF: <filename>
FNLZR: Post-Link Mode
FNLZR: Flags [ 1 | 0 ]           // capmerc=1, sass-only=0
FNLZR: Starting <filename>
  ... mercury relocation application ...
FNLZR: Ending <filename>

Merge Phase: Section Skipping

During the merge phase (sub_45E7D0), Mercury-specific sections are conditionally skipped and deferred to FNLZR. The function emits a debug trace when skipping:

// sub_45E7D0 at 0x45F624
fprintf(stderr, "skip mercury section %i\n", section_index);

This skip logic is gated by the 0x10000000 flag in the section's sh_flags field, which marks Mercury-specific sections that should not be merged by the standard section merger.

Relocation Phase: Dead Code and YIELD Handling

The relocation phase (sub_469D60) contains Mercury-specific dead-code and YIELD-conversion logic:

1. Dead function elimination: When a relocation targets a dead function (binding type 1 with no name), the reloc type is zeroed and a debug trace is emitted:

   fprintf(stderr, "ignore reloc on dead func %s\n", symbol_name);
   rela_entry.type = 0;   // convert to R_MERCURY_NONE
   

2. YIELD instruction conversion: Relocation types 68--69 (0x10044--0x10045, which map to R_CUDA YIELD types when using Mercury indexing) trigger special handling. When the forward-progress requirement flag (context + 94) is set, the linker ignores the YIELD-to-NOP conversion relocation:

   fwrite("Ignoring the reloc to convert YIELD to NOP due to forward progress requirement.\n",
          1, 0x50, stderr);
   

Capmerc Self-Check and Uplift

Self-Check Infrastructure

nvlink includes a self-check mode activated by --self-check (registered in sub_4AC380 at 0x4AC380). When active, the linker verifies that Mercury relocation application produces correct results by comparing the patched output against expected values. The diagnostic messages and their binary addresses:

The self-check strings at 0x2458F38--0x2458FE8 are organized as a pointer array at 0x24590A0--0x24590B8, suggesting a table-driven diagnostic approach where section indices map to error messages.

Mercury Uplift

The "mercury uplift" path converts non-Mercury binaries to Mercury format. The sub_4AC380 function also registers related options:

Third Name Table at 0x2459160

The R_MERCURY_NONE string at 0x1D35A17 has three xrefs: the primary name table (0x1D371E0), the descriptor table (0x1D3CBE0), and a third pointer at 0x2459160. This third reference is in the capmerc uplift/self-check code region and represents a separate copy of the name table used by the Mercury-to-SASS reconstitution path for relocation name lookup during verification.

R_MERCURY vs R_CUDA Comparison

The following table maps each R_MERCURY type to its closest R_CUDA equivalent. Mercury's type set is a strict subset of R_CUDA's semantic categories, omitting instruction-encoding-specific types.

Design Philosophy: Position-Independent Types

The central design difference between R_MERCURY and R_CUDA relocations is the elimination of bit-position encoding from the type name. R_CUDA has 119 types because the same semantic operation (e.g., "patch a 32-bit absolute address into an instruction") requires separate type numbers for each instruction generation's bit-field layout. Mercury consolidates these into single types, pushing the bit-position information into the descriptor table.

This design has several consequences:

1. Type count reduction: 65 types vs 119, despite adding 15 new categories (PC-rel 64-bit, byte-level PC-rel, absolute PC-rel)
2. Forward compatibility: New Mercury instruction encodings with different bit-field positions need only new descriptor table entries, not new type numbers
3. Simpler compiler output: The compiler emits generic relocation types and the linker's descriptor table provides the architecture-specific bit-field mapping
4. Shared engine: The sub_468760 engine works identically for both CUDA and Mercury because the bit-field information is always in the descriptor, never in the type-based code path

Categories Present in R_CUDA but Absent from R_MERCURY

R_MERCURY omits the following R_CUDA relocation categories entirely:

Categories Present in R_MERCURY but Absent from R_CUDA

Most Common Mercury Relocations

Based on the type semantics and their positions in the table, the following relocations appear most frequently in typical Mercury binaries:

Kernel Code Relocations

Data Section Relocations

Unified Table Relocations

Worked Example: Branch Relocation

A Mercury BRA instruction targeting function _Z6kernelPf generates a R_MERCURY_PROG_REL32 relocation:

Section .rela.text, offset 0x180:
  r_offset = 0x00000050    (byte offset of the BRA instruction in .text)
  r_info   = 0x0003 10008  (symbol index 3, type 0x10008 = R_MERCURY_PROG_REL32)
  r_addend = 0x00000000

The linker resolves:
  S = symbol_value(_Z6kernelPf) = 0x00000200
  A = r_addend = 0
  PC = section_base + r_offset = 0x00000050
  result = (S + A) - PC = 0x200 - 0x50 = 0x1B0

The descriptor for type 8 (PROG_REL32) specifies:
  Action 0: bit_offset=X, bit_width=32, action_type=0x10 (pc_rel)
  The engine writes 0x1B0 into bits [X:X+32) of the 128-bit instruction at offset 0x50.

Worked Example: Byte-Level Data Patching

A global variable address 0x00007FFF12345678 must be written byte-by-byte into a descriptor table entry at offset 0x40:

8 relocation entries, one per byte:
  R_MERCURY_G8_0   at offset 0x40: writes 0x78 (byte 0)
  R_MERCURY_G8_8   at offset 0x41: writes 0x56 (byte 1)
  R_MERCURY_G8_16  at offset 0x42: writes 0x34 (byte 2)
  R_MERCURY_G8_24  at offset 0x43: writes 0x12 (byte 3)
  R_MERCURY_G8_32  at offset 0x44: writes 0xFF (byte 4)
  R_MERCURY_G8_40  at offset 0x45: writes 0x7F (byte 5)
  R_MERCURY_G8_48  at offset 0x46: writes 0x00 (byte 6)
  R_MERCURY_G8_56  at offset 0x47: writes 0x00 (byte 7)

Each relocation uses a masked_shift action:
  G8_0 -> action_type=0x16, mask=0x00000000000000FF, shift=0
  G8_8 -> action_type=0x17, mask=0x000000000000FF00, shift=8
  ...
  G8_56 -> action_type=0x1D, mask=0xFF00000000000000, shift=56

ELF Attribute Relocations

Mercury attribute relocations use the same 0x10000 offset mechanism within the attribute relocation table at off_1D371E0. When the relocation engine encounters a type >= 0x10000 in an attribute section (.nv.info.*), it subtracts 0x10000 and indexes into this table.

The attribute table has 65 entries (indices 0--64), validated with the limit check type_index >= 0x41 in sub_42F6C0. The validation function at sub_42F760 handles attribute-specific compatibility with a three-way dispatch:

// sub_42F760 at 0x42F760 -- attribute validation
if (type_index > 0x60)       // > 96 -- guard against out-of-bounds
    error("unknown attribute");

if (dword_1D37D68[4 * type_index] > target_arch_class) {
    switch (dword_1D37D68[4 * type_index + 1]) {   // usage field
    case 0: warning("Attribute %s not supported on %s", name, class_name); break;
    case 1: error("Attribute %s not supported on %s", name, class_name); break;
    case 2: /* silent ignore */ break;
    default: error("unknown usage"); break;
    }
}

The EIATTR types specific to Mercury are:

And the compatibility attributes:

These attributes are not relocation types but are processed alongside relocations during the .nv.info section handling phase. The EIATTR_MERCURY_FINALIZER_OPTIONS attribute is particularly important because it controls how the FNLZR processes relocations -- it can enable or disable specific finalization passes that affect relocation resolution.

Summary Table by Category

Function Addresses

Confidence Assessment

Cross-References

nvlink Internal

• Mercury Overview -- Mercury architecture and string evidence
• Mercury ELF Sections -- .nv.merc.rela section that carries these relocations
• Capsule Mercury Format -- capmerc container format
• FNLZR -- finalizer that applies Mercury relocations (sub_4275C0, sub_4748F0)
• R_CUDA Relocations -- the 119 R_CUDA relocation types (shared engine, same descriptor format)
• R_MERCURY Catalog -- pure reference listing of all 65 types with string addresses
• R_CUDA Catalog -- companion CUDA catalog for cross-reference
• Relocation Engine -- shared sub_468760 engine pseudocode and action type table
• Section Merging -- relocation processing during merge (Mercury skip logic)
• Bindless Relocations -- bindless texture mechanism (absent from R_MERCURY)
• UFT -- Unified Function Table referenced by R_MERCURY_UNIFIED_* types
• Function Map -- master function address index

Sibling Wikis

• ptxas: Capsule Mercury & Finalization -- standalone ptxas capmerc relocation emission (Mercury rela entry format, relocation table layout)