R_MERCURY Relocation Catalog

Complete reference listing of all 65 R_MERCURY relocation types defined in nvlink v13.0.88 for the capsule Mercury (capmerc) binary format. The binary contains 71 total R_MERCURY/MERCURY-bearing strings: 65 relocation type names, 2 trailing-space formatting duplicates, and 4 .nv.info attribute names -- all documented below. For semantic details, descriptor table structure, and dispatch logic, see R_MERCURY Relocations. For the CUDA counterpart catalog, see R_CUDA Relocation Catalog.

Encoding

Every R_MERCURY type is stored in ELF r_info as index + 0x10000. The relocation engine subtracts 0x10000 at dispatch time to index into the Mercury descriptor table at off_1D3CBE0. The name table lives at off_1D371E0 with 65 string pointers. The actual name strings occupy a contiguous pool at 0x1D35A17--0x1D35F5F (1,353 bytes including null terminators).

Complete Type Table

65 entries, sorted by index. The "String Address" column gives the .rodata address of each name string as found in nvlink_strings.json.

Category Groups

Group 1: Sentinels (2 types)

The validation function sub_42F6C0 rejects any index >= 65 (0x41) with the diagnostic "unknown attribute". R_MERCURY_NONE produces an all-zero descriptor; the application engine returns immediately without patching.

Group 2: Global Address (1 type)

Primary relocation for global memory addresses (.nv.global, .nv.shared). Writes the full 64-bit result. Mercury has no 32-bit global counterpart (R_CUDA has both R_CUDA_G32 and R_CUDA_G64).

Group 3: Absolute Data (5 types)

Used for data sections and instruction immediates with absolute addressing. The _LO/_HI pair splits a 32-bit address across two instruction fields. Mercury uses a single position-independent type per width, unlike R_CUDA which has separate types per bit-position (R_CUDA_ABS32_20, R_CUDA_ABS32_23, R_CUDA_ABS32_26, R_CUDA_ABS32_32). The bit-field position is stored in the 64-byte descriptor entry, not the type name.

Group 4: PC-Relative (4 types)

Branch and call instructions (BRA, CALL, BRX). The PROG_REL prefix distinguishes these from the CUDA naming convention (PCREL_IMM24). Mercury supports 64-bit and 32-bit full-width PC-relative offsets plus a 16-bit split pair, versus CUDA which has only 24-bit PC-relative with bit-position variants. These four types have no direct R_CUDA equivalent (CUDA has R_CUDA_PCREL_IMM24_26 and R_CUDA_PCREL_IMM24_23 only).

Group 5: Texture / Sampler / Surface (3 types)

These patch merged header table indices into instruction operands. During linking, per-module header tables are merged into a single global table; these relocations update references to the correct merged entry. Direct semantic equivalents of the R_CUDA *_HEADER_INDEX types.

Mercury drops the SLOT, HW_DESC, HW_SW_DESC, and BINDLESSOFF variants present in R_CUDA (18 types reduced to 3), consolidating resource binding into the header index mechanism alone.

Group 6: Clear (1 type)

Zeroes a 64-bit field in merged data sections or nullifies unused instruction fields. Mercury has only the 64-bit variant; R_CUDA additionally has R_CUDA_UNUSED_CLEAR32.

Group 7: Function Descriptor (1 type)

Resolves a reference to a function descriptor entry for indirect calls, virtual function tables, and device-side function pointers. Mercury has only the 64-bit variant; R_CUDA additionally has R_CUDA_FUNC_DESC_32 and 9 positional R_CUDA_FUNC_DESC32_* types.

Group 8: Byte-Level (8 types)

Patch a single byte within a 64-bit data word. The suffix denotes the bit offset (byte 0 = bits 0--7, byte 7 = bits 56--63). Used for descriptor tables, attribute sections, and data structures requiring individual byte resolution. Direct equivalents of R_CUDA_8_0 through R_CUDA_8_56.

Group 9: Global Byte-Level (8 types)

Byte-granularity variants of R_MERCURY_G64. Write a single byte of a global address at the specified position. Direct equivalents of R_CUDA_G8_0 through R_CUDA_G8_56.

Group 10: Function Descriptor Byte-Level (8 types)

Byte-level function descriptor address patching. Mirrors the R_MERCURY_FUNC_DESC_64 / byte-level split pattern. Direct equivalents of R_CUDA_FUNC_DESC_8_0 through R_CUDA_FUNC_DESC_8_56.

Group 11: Absolute PC-Relative (4 types)

Hybrid absolute/PC-relative relocations computing an unsigned distance rather than a signed offset. Used for instruction encodings that require a non-negative displacement. The _LO/_HI split (indices 40--41) and the full-width variants (indices 60--61) appear at non-contiguous positions in the table, suggesting the split variants were defined first and full-width types were appended later.

No R_CUDA equivalent exists. This is an entirely Mercury-specific category.

Group 12: PC-Relative Byte-Level (8 types)

Byte-level PC-relative patching for data tables (jump tables, exception tables) where PC-relative distances are stored in byte-addressable format. No R_CUDA equivalent exists. This is an entirely Mercury-specific category.

Group 13: Unified Table (12 types)

Relocations for the Unified Descriptor Table (UDT) and Unified Function Table (UFT), used for CUDA Dynamic Parallelism and indirect function calls. R_MERCURY_UNIFIED (index 50) is a generic marker resolved to type 0 (no-op) before the relocation engine runs, because the unified table manager computes final offsets earlier in the pipeline.

The UNIFIED32_LO/UNIFIED32_HI pair (indices 62--63) is non-contiguous with the main unified block (50--59), placed after the ABS_PROG_REL types. Direct semantic equivalents of the R_CUDA UNIFIED* family.

Category Summary

R_CUDA Equivalence Summary

Of the 65 Mercury types, 50 have a direct R_CUDA semantic equivalent and 15 are Mercury-specific additions.

50 types with R_CUDA equivalents:

• Sentinel: NONE, NONE_LAST (2)
• Global: G64 (1)
• Absolute: ABS64, ABS32, ABS16, ABS32_LO, ABS32_HI (5)
• PC-relative: PROG_REL32 maps loosely to R_CUDA_PCREL_IMM24_* (1)
• Texture/sampler/surface: TEX_HEADER_INDEX, SAMP_HEADER_INDEX, SURF_HEADER_INDEX (3)
• Clear: UNUSED_CLEAR64 (1)
• Function descriptor: FUNC_DESC_64 (1)
• Byte-level: 8_* (8), G8_* (8), FUNC_DESC_8_* (8) = 24
• Unified: UNIFIED, UNIFIED_32, UNIFIED_8_* (10), UNIFIED32_LO, UNIFIED32_HI = 12

15 Mercury-specific types (no R_CUDA counterpart):

The Mercury-specific types break into three families:

1. PC-relative extensions (indices 7, 9--10, 42--49): 64-bit PC-relative, split 32-bit PC-relative, and a full byte-level PC-relative set. R_CUDA has only 24-bit immediate PC-relative (R_CUDA_PCREL_IMM24_23, R_CUDA_PCREL_IMM24_26).
2. Absolute PC-relative (indices 40--41, 60--61): Unsigned distance computation (|S + A - PC|). No R_CUDA counterpart.
3. Naming simplification (not counted above): Where R_CUDA encodes the bit-position in the type name (e.g., R_CUDA_ABS32_20, R_CUDA_ABS32_23, R_CUDA_ABS32_26, R_CUDA_ABS32_32 -- four types for the same semantic), Mercury uses a single position-independent type (e.g., R_MERCURY_ABS32). The bit-field position is encoded in the 64-byte descriptor, not the type name. This collapses 25 CUDA ABS*_<bitpos> instruction types into 5 Mercury ABS* types.

R_CUDA Categories Absent from R_MERCURY

Total: 68 R_CUDA types have no R_MERCURY counterpart, reducing 117 to 50 shared types.

String Table Details

The 65 primary name strings occupy a contiguous region at 0x1D35A17--0x1D35F5F (1,353 bytes). The strings are densely packed with no padding between entries (each string is null-terminated and the next string begins at the next byte).

The R_CUDA name strings begin immediately after at 0x1D35F60 (R_CUDA_NONE), forming a single contiguous string pool for all relocation type names.

Trailing-Space Duplicates

Two additional strings with trailing spaces exist at separate .rodata addresses just before the Mercury descriptor table:

The corresponding R_CUDA trailing-space duplicates are adjacent:

All four trailing-space strings cluster at 0x1D3CB71--0x1D3CBC6, 26 bytes before the Mercury descriptor table at 0x1D3CBE0. These are formatting artifacts in .rodata -- name strings embedded within or adjacent to descriptor table entries, not distinct relocation types. Only the UNIFIED_8_0 and UNIFIED_8_8 entries have this artifact; the other 63 entries reference strings from the primary name pool.

EIATTR / EICOMPAT Attribute Names

Four additional Mercury-related strings appear outside the relocation name table:

These are .nv.info section attribute names processed alongside relocations during the attribute handling phase, not relocation types themselves.

String accounting: 65 relocation names + 2 trailing-space duplicates + 4 EIATTR/EICOMPAT attributes = 71 total MERCURY-bearing strings in the binary.

Binary Addresses

Descriptor Table Overlap

The Mercury descriptor table's last entry (R_MERCURY_NONE_LAST at index 64, address 0x1D3DBE0) occupies the same 64 bytes as the CUDA descriptor table's first entry (R_CUDA_NONE at index 0, address 0x1D3DBE0). Both are sentinel no-op entries with identical all-zero descriptors. The binary exploits this by sharing the memory:

Mercury table:  [entry 0 ... entry 63] [entry 64 == CUDA entry 0]
                0x1D3CBE0              0x1D3DBE0
CUDA table:                            [entry 0 ... entry 116]
                                       0x1D3DBE0              0x1D3F920

This saves 64 bytes in .rodata by overlapping the Mercury end-sentinel with the CUDA start-sentinel.

Name Table Entry Format

Each entry in the name table at off_1D371E0 is 16 bytes (2 qwords = v7[2 * index] in sub_42F6C0):

+0  char*    name_ptr      // pointer to null-terminated name string
+8  uint32_t field_0       // metadata (used in validation: v8[2] == max_elf_class)
+12 uint32_t field_1       // metadata

The validation function accesses *((_DWORD *)v8 + 2) (offset +8, field_0) to compare against a2 (an ELF class parameter), rejecting relocations whose ELF class exceeds the maximum supported by that type. This is the per-type architecture compatibility check.

Cross-References

Internal (nvlink wiki):

• R_MERCURY Relocations -- Semantic details, descriptor table structure, and dispatch logic for Mercury relocation types
• Relocation Engine -- Shared CUDA/Mercury application engine (sub_468760) that processes both descriptor tables
• R_CUDA Catalog -- The CUDA counterpart catalog with 117 relocation types
• Mercury Overview -- High-level Mercury architecture context for the capsule Mercury binary format
• Capsule Mercury Format -- Binary layout of the capmerc format that uses R_MERCURY relocations
• Bindless Relocations -- Texture/surface relocation handling shared between CUDA and Mercury types

Sibling wikis:

• ptxas: Relocations -- ptxas-side relocation emission that generates the R_MERCURY entries nvlink processes

Confidence Assessment

Spot-Check Table (12 entries)

All 12 spot-checked names found verbatim in nvlink_strings.json at their documented addresses:

Per-Aspect Assessment