<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/202194>202194</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [RISC-V][lld] RISC-V TLS GD explicit addend wrong output
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            lld
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          XiaobingHou1219
      </td>
    </tr>
</table>

<pre>
    I ran into this while reducing a RISC-V linker testcase. The reproducer is small, and I have been seeing the same result consistently across three reruns.

### Summary
ld.lld links successfully but for `la.tls.gd a0, tls+4` rewrites the GD address materialization to target the GOT pair plus 4 bytes and leaves the local static GD addend word equal to the plain control. The equivalent offset-symbol control `la.tls.gd a0, tls_off`, where `tls_off` is actually placed at TLS offset 4, stores the expected offset-4 word in the second GD slot and targets the GOT pair start. The plain `la.tls.gd a0, tls` control again matches the `tls+4` row, isolating the failure to explicit addend handling in the GD GOT path.

### Expected behavior
Link valid RISC-V shared objects whose TLS Global-Dynamic access uses an explicit addend, for example `la.tls.gd a0, tls+4`. A correct link must preserve the requested TLS offset in the local GD GOT pair and keep the generated `auipc`+`addi` sequence addressing the start of that pair.

### Environment
- linker route: GNU as 2.45 input with `-mno-relax`, current ld.lld 22.1.0 shared links, RV32/RV64 local addend variant plus offset-symbol and plain controls; GNU ld.bfd 2.45 provides an independent addend-drop contrast.
- march: rv32imac and rv64imac
- mabi: ilp32 and lp64
- first failing stage: link
- local stability check: True

### Reduced testcase
These are the reduced input files from the minimized reproducer I used locally:

#### `local_addend_rv64.s`
```asm
.text
.globl _start
_start:
 la.tls.gd a0, tls+4
  call __tls_get_addr
  ret

.section .tbss,"awT",@nobits
tls:
  .zero 8
```

#### `local_offset_symbol_rv64.s`
```asm
.text
.globl _start
_start:
  la.tls.gd a0, tls_off
  call __tls_get_addr
 ret

.section .tbss,"awT",@nobits
tls:
  .zero 4
tls_off:
  .zero 4
```

### Reproduction notes
- Reproduction command from the packaged case directory:
  `powershell -ExecutionPolicy Bypass -File ./case/run.ps1`
- The reduced inputs live under `case/` and the stable witness outputs live under `verify/run1..run3/`.

### What I checked
- Reduced inputs are preserved under case/.
- Stable witness outputs are preserved under verify/run1..run3/.
- The strict recheck says stable normalized run signatures across three runs: True.
- Tracker guidance link: https://llvm.org/docs/HowToSubmitABug.html
- evidence summary: 3 clean reproductions under hunt/verify/tls_gd_addend_wrong_output/run1..run3` are stable: each run reports 2 ld.lld rows as `wrong_addend_used_as_got_offset` and 2 GNU ld.bfd rows as `wrong_addend_dropped`. Representative run1 RV64 `local_addend.64.lld.so` has first GD relocation offset `0x2478`, decoded `la.tls.gd` target `0x247c`, and `.got` ending in `...00f8ffffffffffff`, which matches the plain control instead of the offset-symbol control `...04f8ffffffffffff`. The canonical RV64 repro in `hunt/cases/confirmed/riscv_tls_gd_addend_wrong_output` reproduces the same contrast with `run.ps1`. Local records previously covered TLSDESC explicit-addend roots, one TLSDESC-to-IE relaxation root, and ordinary TLS IE GOT addends, but not ordinary TLS GD addend handling. Web searches across LLVM GitHub issues/PRs, Sourceware Bugzilla/list archives, and broad web queries for `la.tls.gd`, `R_RISCV_TLS_DTPMOD64`, and explicit addends found assembler/docs/tests and TLS implementation patches but no direct current report for this lld failure.

### Notes
upstream/binutils-gdb-full/ld/testsuite/ld-riscv-elf/tls.s` and `tls.d`. Current lld source documents the RISC-V TLS relocation scan path and target relocation kinds, including `R_RISCV_TLS_GOT_HI20` handling and `tlsGotRel` definitions: https://codebrowser.dev/llvm/lld/ELF/Relocations.cpp.html , https://codebrowser.dev/llvm/lld/ELF/Arch/RISCV.cpp.html , and https://codebrowser.dev/llvm/lld/ELF/SyntheticSections.cpp.html . From those sources and the offset-symbol control, the root-cause inference is that the explicit GD addend is not carried into the local GD GOT payload and is instead applied to the pair address materialization.

Root key: `lld.riscv.tls_gd_addend_used_as_got_offset`
Case id: `20260605-lld-riscv-tls-gd-addend-used-as-got-offset`

</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJysWFtT47jz_TTmpcsu44QADzzAZMJQxV4K-M_-31Ky1Im1yJJHl4TMp_9VS3IuLOxWbe0UNZC41epunT59ZOacXGvEm-LirriYn7HgO2Nv_l8y00q9_mbCeXN-fdYasbt5AMs0SO0N-E462HZSIVgUgUu9BgZPD89fyu-gpH5FCx6d58xhBS8dmQ3WiMDRgnTgeqZU0XwBpgU8QMc2CC2iBodIvnyH4FhPy1xQHrjRTjqP2qsdMG6Nc-A7i2Rgg3ZVUc-L-jb_30zSDzyHvmd2l75WolJKxOgcuMA5OrcKSu2gDR5WxkIxqxWrvHLVWgCrKT6vXNHcTYtZDRa3Vnp0Mbj7OTAhLDoHPfNoJVPyJ_PSaKDyMLtGnwx_e4GBSQuDCg6m0O7IBaWtkG2yN2U4U-A885Jn16gFbI0VgD8CU9FphzAoJjVVw1ujUmHxR5AbplB7MKuVQ1-6Xd8aNVp9ktXSrFbFLH7admiRzA5f0xkx7gOj8gyKcRTAPLw8PudNYEornTc2p4BvA3KPYgximqKXOp0lcqMFpeaU8TH9VCN3WiTnmfUpr5TqJ0cyq_fpsTXZ9czzLoeSMtkfm9nSKumMYn7E1opJFSxSWfFtUJJLPxa9Y1oossuh389zeL77BGVfx9Rb7NhGGpsMHqV-hQ1TUoyN4TpmqULtn8g99Y9xGGt6r0zLVDnfadZLDixiE4KLSHkfIWVDaMU31g8K_x61FdwCN9Yi9xH50AfnYbDo0G4wJmjxR0BH8R8db04-AXNfAmnj0b0iDvHxGjVaRkuLWc2CHHiE1B19EkJS-R151xzHdtl3N500mBX4jvno-rPq6o20RveofXpUjgRjTfBYTG7h_tf_A-agqaYXIPUQPGyl7yimstemtKjYW8Y6D9ZSq2QyaJrqvKrHg4nUQFZP3ydN0Syevs-muQQZHBtmJdM-NfNpu1FhTtrTFZO7GJoSVbsSKbzBmo0U6VylFjigFhRP8l8Ka4a0njlfjfn2zPKOErWbSSN7xuNmdjOb0oeDVSvJSKph0iSGGWbT8elKWucj7ukEnGfrWDpKeV_WkYVaqaTfAe-Qv5LRiw348eE8Efmj2HN9ev7SoUNgdsRXskkns5IKHays6ePDXmrZy58ojgfEA0FfpHjUrpjcfrg57U_YJ6tlqt-SalIRPWTbWZ1-mOvTN5XHt4yjaq1Mq2AZkZi-yn-PG8JnfZWeAoUHyyXR5ho9xWDHRxb9cdCVQx6HQ-VbRxArmoZtX4qmob-ntTat9C7Z0ib7CKD6idbA1bt8_rkgCZzLBM7_ui4fFSZOjn8szH9cl-n-Udz-k8d_XzZ4ysiLgWjj0Y0dcfKEm76nrtpjd2D8la1RACEfhCSSNXZ3FEUxqwezRes6VArKr2_IA_n63SjJd3C3G5hzUC5IR1VFs4gt1Cxs0NXgzvcBl1lBHfWRAyU3CEELjLolryTGjcM1MWyrkKhQ0zQxwX-wboNWrnZpz_OqskFPkptP2PgPYuuHRA0oDnU6CY06fxwxIu-VA9xz2vPH0X209OMYq-PaOG8l92AxBgaO7dyYvza2J3FGFBM0kNxlPpBsOdWRQbuR6w6uLeM0adZBCkZDLNLl5BY674eIxmZRNAulNn1l7LpoFsJwVzSLb2b7Yp5D20t_exfWVed7NTpFGgDkzGV1OrmFCXCFTO9JkEDicvpd0L5oFvsqxK4SI-NtrdHrZSrfaYkICnaEAW2CjHexBhYHY72DZhyD1mwdTdBiVid_2TnR8JK55dr4TCgjwJrjyfbZcppmA4ooQ6iV0KEmjbuJ5T6HOF_fUXg1m1JIlTO0Vcdcnlz3c7BIhrEXs0opZnX91kwvr_J0F8iNSGpkz1DkJuvx0Zxnc0qEglubmBdqkXUffVlVdb26Wh3928tlybsTwXky9kFq55GJpG3wc1FOO0z_skMSv5xpoyWN41ijCIscWIYD9RMhjRu9krZHQYcvHd8s_wYf8RaTx6w7XLJGwbGXTQcCquAxqgKL3FjhqDc30gSndsDNBm1SjfOvz1_2MrXMWska46OaMhpHo9Kb8uErREWWTpKsxrMwVkjN7C4K0YevUXQmZ9EPXdO08admh9vSKNwr-ANbcEii6dDlj4_ff4F76b-FFqRzIRbv96fo-NkEy3FL3XIX1j-lUoy6WjoP5ERu0I0httYwAVts4UdAK0nKvLs4ZpQUs_ppSbr_-_Ll8Xk5f_n9l9_ms-kR8t7JevIUtADmHPatQntgE1JX6c5IGUtS_X3qJKPpYhLzTNXJY2ivc1OrxyDjnZ26PV9-PmH4Xw8DMAzOW2R90SxaqYOXypVr0ZZ0a6YCiTG2ID3GL8oIwRLVKhFV1Bxjn9HnRAZfRhWuBLhYfBCGB0oqwTJfmCjdo653nMV8u6ML5PHzV5mRIjVXITbzu2O4_-1l-e2hqRO35IveIbx7459Q0UOBK6llpOG_8j2RTEukh7YSuMkTIP6iknx9JKOnfVyu4sMQRwBQcP_C1y3p_2YR8zh1RrH_C4fPO-079JI_J_11FGIFiyRw6HKaDsftNcWHZBYFIAkUY3zJWXAIUq_QxiEnXbrh5XcECfGHppUutjRn1sooIPKLjncXz52itmNpwUiwbBgULRrfjcTr6ccvZU6w_mSMh1eMg5c6V4kqwrY6Zc4Ph1_y8IUEnxTZQVM3s3pWX5Rq3wA-dkpmwpI8lcyVa-PLd57OxM1EXE-u2RnenF9e1VeTy7q-POtuJlO8vppdXV5f4gxxWl9xMZlNJ5ft-YRPmourM3mT9708by5m08vq-nqCl4JdXbYXkws-EcW0xp5JVY3y5CzyHi07v56eKdaicvG9X9NEbDTFxfzM3pB52Ya1K6Y1caA7OPDSq_iqMPVncTEvLu5o7cX8uGXv5395qxLHUFZ5Z8Gqm1PQrqXvQltx0x_jddOXgzV_IqeBtyftHP_mpvlfAAAA__9TDdHQ">