R_CUDA Relocation Catalog

Complete reference table of all 117 canonical R_CUDA relocation type names extracted from nvlink v13.0.88, indexed across 182 total descriptor rows (117 standard + 65 attribute). The raw nvlink_strings.json pool contains 119 R_CUDA string entries -- 117 unique names plus two trailing-whitespace duplicates of R_CUDA_UNIFIED_8_0 and R_CUDA_UNIFIED_8_8 (see Confidence Assessment). Types are organized into two descriptor tables: the standard table at off_1D37600 (117 entries, indices 0--116) and the attribute table at off_1D371E0 (65 entries, indices 0x10000--0x10040). See R_CUDA Relocations for the relocation engine, descriptor format, action types, and architecture class system.

Standard Table (off_1D37600)

117 entries. Index = raw r_type value in .rela.* sections. Bit width and bit position are derived from the type name and confirmed against the 64-byte descriptors at off_1D3DBE0.

Attribute Table (off_1D371E0)

65 entries. Attribute relocations apply to .nv.info.* metadata sections rather than instruction streams. The encoded r_type in ELF is 0x10000 + index (e.g., attribute index 3 = r_type 0x10003). The attribute table reuses a subset of the same type names as the standard table but with different 64-byte descriptors.

The attribute table entries are not individually named in the binary -- they share string pointers with the standard table. The following mapping lists the 65 attribute indices and the standard-table name each one references. Indices not listed here (gaps) use R_CUDA_NONE.

Category Summary

Descriptor Byte Layout

The 117 standard and 65 attribute descriptors are stored as 64-byte fixed records in .rodata. Both the standard table at off_1D3DBE0 and the attribute table at off_1D3CBE0 share the same layout; the relocation engine picks one or the other from the r_type & 0x10000 attribute bit (see sub_469620 lines 26--38). This section provides the byte-for-byte decode that confirms the three-action-slot model described in R_CUDA Relocations § Descriptor Format.

Verified byte layout

offset  size  field             role
------  ----  ----------------  ----------------------------------------------
 0..7    8    name_ptr          LE pointer to type-name string in .rodata
 8..11   4    apply_class       1=instr bit-field, 2=descriptor/global, 4=data,
                                0=sentinel, 0xFF00=poison terminator
12..15   4    slot0.bit_offset  primary bit position to patch
16..19   4    slot0.bit_width   primary bit-width to patch
20..23   4    slot0.action      action enum (0..56)
24..27   4    slot0.aux         per-action immediate (HI-byte addend, byte offset)
28..43  16    slot1             second action: (bit_offset, bit_width, action, aux)
44..59  16    slot2             third action:  (bit_offset, bit_width, action, aux)
60..63   4    sentinel          zero -- terminates the action-slot iterator

The 12-byte header in r-cuda-relocations.md § Descriptor Format corresponds to the name_ptr (treated as two consumed _DWORDs field_0/field_1 by sub_46ADC0) followed by the apply_class dword. This catalog labels the first 8 bytes as a single name pointer because every observed value is a valid .rodata string address.

ASCII byte map

byte:   0  1  2  3  4  5  6  7   8  9  A  B   C  D  E  F  10 11 12 13  14 15 16 17
       [ name_ptr (qword)     ] [apply_class] [slot0.boff] [slot0.bwid] [slot0.act ]

byte:  18 19 1A 1B  1C 1D 1E 1F  20 21 22 23  24 25 26 27  28 29 2A 2B  2C 2D 2E 2F
       [slot0.aux ] [slot1.boff] [slot1.bwid] [slot1.act ] [slot1.aux ] [slot2.boff]

byte:  30 31 32 33  34 35 36 37  38 39 3A 3B  3C 3D 3E 3F
       [slot2.bwid] [slot2.act ] [slot2.aux ] [ sentinel ]

apply_class enum (dword at byte 8)

This enum is not the action selector; it is a coarse classifier consumed by the dispatcher in sub_4698A0 and sub_469790 that decides which top-level patch path to take. The fine-grained operation is encoded in slot0.action.

action enum (dword at byte 20)

Twenty-three distinct action codes appear in the standard table. The bitmask test in sub_469620 line 46 (_bittest64(0x3FFFE002C6, action)) gates the symbol-resolution branch on actions {1, 2, 6, 7, 9, 17, 18, 19, 20, 21, 22, ..., 33, 37} -- the entries that need late symbol fix-up.

Slot usage statistics

Of the 117 standard descriptors:

• 108 entries use slot 0 only -- slot 1 and slot 2 are zero, and only one patch action runs.
• 8 entries use slot 0 + slot 1 -- multi-piece encodings split across two bit ranges.
• 1 entry (R_CUDA_CONST_FIELD19_28) uses all three slots: 14 bits at position 28, plus 4 bits at position 42, plus 1 bit at position 26.

The action engine in sub_468760 iterates slot0 → slot1 → slot2 → sentinel, applying each non-zero action in turn. A zero action byte in any slot is skipped, not treated as a real type-zero patch.

Decoded sample entries

The following entries were byte-decoded against nvlink_rodata.bin (rodata offset 0xBA40, equivalent to RVA 0x1D3DBE0):

bit_offset and bit_width recovered from the descriptors agree byte-for-byte with the values parsed from the type-name suffixes in the standard table above for every entry where the suffix is unambiguous. Where the name encodes a single bit-width (e.g. R_CUDA_ABS55_16_34), the descriptor splits it across two slots whose widths sum to the advertised value.

⚡ QUIRK -- diagonal-0xFF terminator on R_CUDA_NONE_LAST The final standard-table entry (idx 116) is not a real descriptor. Its 64 bytes form an 8×8 grid with 0xFF on the diagonal and zeros elsewhere, so the name pointer reads as 0x00000000_000000FF, the apply-class as 0xFF00, and the sentinel slot at byte 60 contains 0xFF000000 -- every parse axis returns garbage. The bounds check at sub_42F6C0 line 23 (a1 >= 0x75) already prevents real dispatch on index 116, so the diagonal pattern functions as a poison page: if anything ever reaches descriptor 116, any field you read will be obviously corrupt. Treat it as a tripwire, not a relocation type.

⚡ QUIRK -- aux overload for HI-half addend versus byte offset The 4-byte aux field at byte 24 (slot0) means different things depending on action. For action 7 (*_HI_* family) it carries the value 0x20 (32 = "shift right by 32 to extract the high half before insertion"). For actions 22..29 / 30..37 / 38..45 / 47..54 (the eight-way 8-bit patch families) it carries the byte offset within the target word -- 0, 8, 16, ... 56 -- exactly mirroring the type-name suffix. The same dword slot therefore encodes either a shift-count constant or a byte-offset constant, with the action enum being the sole disambiguator. Pre-decoding code that treats aux as a single semantic field will misread one family or the other.

⚡ QUIRK -- attribute table reuses payload format unchanged The 65 attribute descriptors at off_1D3CBE0 are not a separate format -- they share the exact same 64-byte layout and the same apply_class / action / slot semantics as the standard table. The attribute bit (r_type & 0x10000) only selects which table the engine indexes (sub_469620 lines 31--38; sub_42F6C0 line 14: a1 -= 0x10000). String pointers in attribute-table records point into the same .rodata string pool used by the standard table, which is why the two tables share names by pointer equality. No attribute-specific action codes exist; the only difference is the consumer -- the .nv.info.* parser for attribute relocations versus the instruction-stream patcher for standard ones.

Field cross-check against consumer code

• sub_469620 line 43: v5 = HIDWORD(v3[8 * idx + 2]) reads QWORD index 8*idx + 2 from off_1D3DBE0 cast to _QWORD *. That is byte offset 64*idx + 16; HIDWORD of that QWORD is bytes 20..23 = slot0.action. Bit-tested against 0x3FFFE002C6.

• sub_4698A0 line 37: *((_DWORD *)&off_1D3DBE0 + 16 * idx + 5) -- with 4-byte DWORD stride, that is byte offset 64*idx + 20 = slot0.action. The check action - 12 <= 3 selects actions 12, 13, 14, 15 -- exactly the R_CUDA_FUNC_DESC32_* family.

• sub_469D60 line 309: *((_DWORD *)v24 + 5) == 16 checks slot0.action == 16, i.e. R_CUDA_PCREL_IMM24_* -- gating the PC-relative branch-offset path.

• sub_468760 (the application engine): iterates the three 16-byte slots from desc+12 to desc+60 using action += 4 (four DWORDs = 16 bytes per slot), confirming the 16-byte stride between slots and the 4-byte sentinel terminator at byte 60.

• Relocation Application Engine -- bit-field patching engine that consumes these descriptors

• Bindless Relocations -- resolution pipeline for bindless texture/surface types

• R_MERCURY Relocation Catalog -- parallel catalog for Mercury (sm >= 100) types

• Binary Layout -- addresses of descriptor tables within the nvlink binary

Confidence Assessment

Verification scope: All 117 standard-table names and 65 attribute-table indices were cross-checked against nvlink_strings.json (exact-string match) and the decompiled table dispatcher sub_42F6C0 (nvlink/decompiled/sub_42F6C0_0x42f6c0.c). Ten entries were spot-checked end-to-end: string presence, string address, and relocation-engine consumption of off_1D3DBE0.

Totals: 117 standard entries + 65 attribute entries = 182 catalog rows. String verification: 119 / 119 raw strings in nvlink_strings.json (includes two trailing-whitespace duplicates of R_CUDA_UNIFIED_8_0 and R_CUDA_UNIFIED_8_8 at 0x1d3cb9f / 0x1d3cbb3) collapse to the 117 canonical names after trimming. Verified: 117 / 117 canonical names. Unverified: 0.

Spot-check table (10 entries)

Cross-reference with the ptxas Relocations page: The ten spot-checked names match verbatim against ptxas lines 80, 124, 140, 155, 179, 195, 217, 242, 244, 248. No ordinal drift between ptxas and nvlink for these entries.