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

    <tr>
        <th>Summary</th>
        <td>
            [RFC] [mingw-w64] Reduce stack protector overhead by marking `__stack_chk_guard` as DSO-local
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            platform:windows
      </td>
    </tr>

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

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

<pre>
    Currently `__stack_chk_guard` is not DSO-local on mingw-w64 target to support linking to libssp as a DLL, as per 78a57069b53a08d5aef98a8472fcfa73dbbc8771. As a result, the stack protector code needs to perform an additional address dereference through the `.refptr` stub, compared to MSVC target.

Since mingw-w64 v11, the functionality of `libssp` has been integrated into mingw-w64-crt, so libssp is no longer necessary and `__stack_chk_guard` is guaranteed to be statically linked. Therefore, I suggest we should start marking `__stack_chk_guard` as DSO-local in LLVM 21 to remove the need to go through `.refptr`, which should give a slight performance boost when stack protector is used.

Demo code:
```c++
#ifdef DSO_LOCAL_STACK_CHK_GUARD
void *__stack_chk_guard __asm__("__stack_chk_guard");
#endif

extern "C" void other(void *);

int func(int v) {
    int buf[16];
    buf[0] = v;
 other(buf);
    return *buf;
}
```
Output: https://godbolt.org/z/5xhsKPqhG

### Backward compatibility issues:

By the time LLVM 21 releases, mingw-w64 v11 would have been released for over 2 years. Nevertheless, some users may be stuck with an older version of mingw-w64 runtime, so we need to consider the backward compatibility.

- If libssp is linked statically, this will still work normally.
- If libssp is linked dynamically, then the linker is forced to generate 32-bit pseudo relocations for `__stack_chk_guard`, and on x86_64, these can fail during run-time if the address offset is larger than 32-bit. LLD does emit warnings for them. This is a breaking change. (The user can work around this by linking libssp statically.)

Is this acceptable?


CC @mstorsjo @lhmouse @lazka @brechtsanders
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyUVl-v2j4S_TTmZQQKToDwwEMuiN9WpdtVb7evyLEniXsdm7UdKP30q3Fy_3Rvu9JPiu41OJ4zc2bOMSIE3VrEHVs9sNVhJobYOb8T5qpt52Q32Fnt1H23H7xHG80d2Do7n0MU8uksu6dzOwiv2DoDHcC6CIfHz3PjpDDgLPTatrf5bV1AFL7FCNFBGC4X5yMYbZ-0bekro-sQLiACCDicTozvaX1BD5tSrDbZeluvcpGVaiWw2ZaiLDa8kY3Y5KquZbnZLBdQ0WGPYTCRzscOISUJF-8iyug8SKcQLKIKBHpB3zjfg7AglNJROysMLT2GAAo9NujRSoTYeTe0XYrJ1tnCY3OJnmoOcagJTbr-Ijwqivvp8dt-KnfBsopl1aOmKK9cXJfL5xSbwcoRWcc7uIbij2xQ-E4EqBEtaBux9SKioqV7jTWXPpUbXkhMbQDjbIseLEoMQfg7CKv-X-doLWzEsYQ6cRe1FMbcU6NQLeBrR5w4jwT4AcLQthgi3BBC5waj6IyP0Auf-vonNBHezIi2cDp9-wR8Sbgee3fFRIydUmndC_2_UE853Dotu2fwVl8RBASj2y4-N1cQ8bVzlGaH9t1E6ABDQDX16YC9S0PCcvpIKOmRjD_Qk1WM57pR2FAF59PnfXU6P36t9h_P-398PP_17-rLgWXV1WkFjFfvqofzWYT-fGa8ZJy_J4dzxrcsn4DQKt2MieGPiN4C43zPOIcE4GKHnvHyGe31aFZpG9NkMV7S8sr4FtiGNgGAJgjqoWGrh-WarQ7jKdoYv8zY6gAsP8B12nlGou1nEHrdYxxSVhXtjNibw1viWFZ9HuJliCyvoIvxEohZfmT82DpVOxMXzreMH38yflz96MLHf_2n-2usgfF8fOBByKcb0ZdUFnWtk1h0CAOGqVVZ9XBPcxN1jy8j5dGgCBhoWH6RH9zSzHTiiqPApjcVNM6Du6IHDncUPizgn3hFHzs0GMIotR5panyAXtxHrQzyCW46dmQmzij0cEUftLMk6VdkP1jKbxLs7XXKpbNB0zEqof5tvdOMzuFD80bqozbfqHU0Fh3gpo2BEOnvzfknsCQHY1Kc3wdRdyv6t1HQpnzSdtJK47ycZIkWyY8g5_NaR7gEHBQJmGRNhpZe_pMHJIO3im6IH-X6vC4mvIAghYVGaANq8OQifrDz1FPdpGSe_dk1TcCYsierJeaEnbJZwOl0AOUwAPY6wk14q207phQ77MnLdKDDAmqPIvmV7IRtcQGMl1-7scMpm8Se8G6wamS2vr_cXROHr_QvSCGpUR_C-LaQEi9R1AZZfpxGO6v2e2BF1ofofPjuaG263g0B01L8fBK0qD3KLgZhFfowU7tcbfOtmOFuuSmybZ5vynLW7USBclUXTV2oZbYuS1FnvMw2TbEWdSMLNdM7nvFVlmd8uS7yrFzURV5jvtysM1QcVcGKDHuhzcKYa0-SnCVx7ZZ8WxTFzIgaTUi_EDi_GBHJWlle3bRV7hbIt1aHmd_R6Xk9tIFq0CGG13hRR5N-Y3w57pO_rB5eZEGfv6Aa5Psbm5TYoVDE-d-5V2aDN7v_MRwdu6FeSNczfqS8pn_zi3ffUUbGj5Oj8ONU93XH_xsAAP__rAQF1A">