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

    <tr>
        <th>Summary</th>
        <td>
            16.0.0 KMSAN handles function param/retval shadow state incorrectly
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

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

<pre>
    I encountered this problem in FreeBSD's implementation of KMSAN after updating from LLVM 15 to 16, but I believe the same problem is demonstrated with the examples on godbolt below. It may apply to MSAN as well.

Consider the following function:

```
#include <sys/types.h>

void *mymemcpy(void *dst, const void *src, size_t sz)
{
    char *dstp;
    const char *srcp;
    size_t i;

    srcp = src;
    dstp = dst;
    for (i = 0; i < sz; i++)
        dstp[i] = srcp[i];
    return dst;
}
```

I would expected the generated asm to do at least two things: 1) verify that shadow state for `sz` is 0, 2) copy the shadow state for param `dst` to the retval shadow area in TLS. With 15.0.0 I can see both of these things, and with 16.0.0 (and LLVM trunk) I see neither.

LLVM 16.0.0: https://godbolt.org/z/zvc6Mb5dh
LLVM 15.0.0: https://godbolt.org/z/zxPd3aYh1

At the beginning of the function we load a pointer to the MSAN TLS state (via `__msan_get_context_state()`) and save it on the stack. LLVM 15 immediate loads the value at offset 0x10 of the TLS, which corresponds to the shadow state for `sz`, and effectively jumps to a `__msan_warning()` call if the value is non-zero, so 1) appears to be satisfied. For 2), the asm does this before returning

```
movq -128(%rbp), %rax  # load TLS pointer
movq    -88(%rbp), %rcx # fetch saved shadow state for `dst`
movq    %rcx, 800(%rax) # 800 is the offset of retval shadow state
...
retq
```

With LLVM 16, the generated code is much shorter, but it doesn't appear to inspect the param shadow state at all, and it unconditionally sets retval shadow state to 0:

```
movq    -80(%rbp), %rax # load TLS pointer
movq    $0, 800(%rax) # 800 is the offset of retval shadow state
```

Isn't LLVM 16's behaviour simply wrong? Are some additional compiler flags needed?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJysVktv4zgS_jX0pRBDoizZPviQxxoINr1YII1dzCmgyJLFbopUk5Qf-fWDoqTEaaR75jCA48gk66vX95UoQtAHi7hj5R0rHxZiiK3zu074799UvaiduuweAa10g43oUUFsdYDeu9pgB9rC3iPePT8wvg6gu95ghzaKqJ0F18C_vzzf_gdEE9HD0CsRtT1A410HT0__-wJ5CdFBXjF-D_UQ4RFqNBqPCLFFCKLDd1cBFHbOhuhFRAUnHdt0Cs-C3AZwFg5O1c5EQnGnJTxG6MQFRN-bCzkagwlwQmOWLHtg2e34fe9s0Ap9AmycMe6UAh2spExYcXt9mlXZ9Bl_8kJbaQaFwIr7cAmM7-Olx7BsWfGva8Oj0woYv-0uHXayvzC-mZdUiFQESQnCvBi8pMWgX_ElQnhlfDvBre_GBwAA2Qo_QfSsuN5IYPN28PLj9gSr3xavtrzsgRUP9PDBhnykDYr3eqNx5GSj02bGijugx3sKmp4Zv0uf7bvFDMfKO83Kh9nd_PsDusc4ePvBKVs_fN6N9P0IJzcYBXjuUcZEW4QDWhzJI0JHfFAORASDIkSIJ0fctofAilvIGd_CEb1uLhBbESG0QrkThCgijslWWXhlVUbEzKhLnEyk6y8jd38-3wsvOrKiJKqM3NM5j_EozHxceBQkqq9Pz0v4PzE8L5fZMoNHkMJCQITaxZaUFVsMOEfM70HYSRN5lSwY39BSkln0g_1O4T0mCIs6tug_KGCUYzKl_NsYeyoE43vG95Osls4fGN-_0t9RVl_qUrXX1uXftj7_VxXijza_juA2poLUeNDWkvrGJN9ECCcE44QCAb3TNI3mGiZZf316nqpNqtKCSv3y0gVhXw4YX6SzEc_xJR1hfENUrDKqCVUpiCOCjjRCUvOikN-XbyNKdx0qTdDkP6QjR2EGJPa4pgkYITvn2Rzx16dn6sip1bIF6bzH0DtLhu5zbsxcmvuITYMy6iOaC3wbuj5ZXmd0Ep5K9JYHSGEM6OYqNB3AOnvzit6lGeJGTou-R-ETYE0TNurQaFRL2DufKEyHCYUkohyGceDX2DiPkw7J86_HYeeOP-Amp9A2jJe-7idU-iHOAIwXYyOpZVMrr0wB4GbzqbE8J9sGo2xTy9SnpRwF9hFxNCegTZZN2OJMBSHETZZkTGlP7XTNT8oceZMwl8tJOR7jj9_MoKTfSVdzVd9HkHQqNakbKJnWearC9BrUMZXeMr6OU8eoYdoGmmYJaBwnH9IXEYQxM4d0hMFKZ5Um8QhjLhAwhs_SIuzs9--4985kv2jrX3eV8VX2z3Tg85E_1eut4muibSuO2g0eAt1NLnDyzh5YsYdbjxBchyDUXCGQruu1QQ-NEYcAFlGhYsV-oXaF2hZbscBdXm222_Vqk28W7a6pRF3VPKsqtc7zEtdlJppCFbLOVbmVzULveMaLbM1znvOq3CyrVcnzjCNu5Ha1Eg1bZdgJbZbGHDuakAsdwoC7apXl24URNZqQ7macWzxB2mSc01XN78jmph4Oga0yo0MM7yhRR0PBplfBeAlrhVV0TXqbp4lCjO8_Y4S2aW7JaC6LwZvdTxNdx3aol9KROfmc_t303n1DGRnfp0jpJpQy-TMAAP__N7U2pA">