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

    <tr>
        <th>Summary</th>
        <td>
            [RISCV] LLVM produces binaries where GNU objdump is unable to use the mapping symbols for proper disassembly
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            backend:RISC-V
      </td>
    </tr>

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

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

<pre>
    It's possible there's a GNU bug here, but it's the case that `clang` produces binaries where GNU objdump can't use the mapping symbols to properly print some instructions, while `llvm-objdump` manages fine. But binaries produced by `gcc` are disassembled properly with either objdump implementation.

Consider the following example, where `max` is a trivial function that will result in the selection of `max` from the Zbb extension. 

```sh
cat - <<EOF > max.c
int max(int x, int y) {
  return x > y ? x : y;
}

int main(void) {
  return 0;
}
EOF
riscv64-linux-gnu-gcc -c -O3 -march=rv64gc_zbb max.c -o max.gcc.o
$HOME/llvm-project/build/default/bin/clang --target=riscv64-linux-gnu -c -O3 -march=rv64gc_zbb max.c -o max.clang.o
riscv64-linux-gnu-gcc -O3 -march=rv64gc_zbb max.c -o max.gcc
$HOME/llvm-project/build/default/bin/clang --target=riscv64-linux-gnu -O3 -march=rv64gc_zbb --sysroot=$HOME/rvsysroot -fuse-ld=lld max.c -o max.clang
riscv64-linux-gnu-gcc -O3 -fuse-ld=lld -march=rv64gc_zbb max.c -o max.gcc.lld
```

The result is:
* max.gcc.o: Disassembles fine for LLVM and GNU objdump
* max.clang.o: Disassembles fine for LLVM and GNU objdump
* max.gcc: Disassembles fine for LLVM and GNU objdump
* max.gcc.lld: Disassembles fine for LLVM and GNU objdump
* max.clang: Disassembles fine for LLVM objdump, but for GNU objdump we get `.insn` printed for the `max` instruction
  * `169a:      0ab56533        .insn   4, 0x0ab56533`

I see this across basically all LLVM/Clang produced binaries.

CC @kito-cheng in case you've seen this as well or have any insight?
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJy0VU1v4zYQ_TX0ZSBDpr6sgw9eO2oD7DZAP3LopSCpscRdijRIyrb66wtSTuy2mzboooAOBMX35g1n-IY5JzuNuCHFB1LsF2z0vbEb5viCm3baPHpCKwdH45zkCsH3aDFuMfjuh1-Ajx3MWzvgowc5n_c9gmAunGceSJkKxXRHyhSO1rSjQAdcamYlOjgHfCQz_HM7DkcQTBNaeRgjAcLAjkepO3DTwI1y4E2gOaJVExyt1B6cGRCkdt6OwkujXdBz7qXCEFyp05BcyYOGgWnWoYOD1LiED6O_ibnKa4FPAdkJEQDMIrTSMedw4ArbW_iz9D2gDNfyKl8OR4UDas-ClCVJtyTd7ox2skUbEzoYpcw5pIQXFk7PcsM9kDId2CUEleGOvZUnyRQcRh0Tmy_0LJUCi25UHqSOlA4VzifM4Y7kYM0Q___KOeDFo3ZBE8yiSJnOn-tJuhXMQwIk25Fs9_DUAMkeYGCXpSDpNlxyoKTrsLoEvWExEVoDqT6QdAtg0Y9WwyUCJyBZE9dbmEgWTpBqP4edyaQmdH0ysv0KR3qPeHhqSLq10olTmSdK6vGSdHpMOiEgEZA8ZZAMzIqeZHt7KvNO_PY757N0SExcdEIsTWCk-fdPnx4IbWJTHK35jMIT2vBRqpbQpsUDG1XcCQKb2LiQJJ7ZDn2I8Fcd79YQqaKKN3J5ZyL_VxpvhE8SNzlrTEDd4trTdReSw-gwUS3J9kq1X0n5nxP-M_pdhVSqvW_eual-7vH1STiSxfam27viZ1vY397w_PrhYCx8_Pj8CZhu7z3oDv1Stv-KDxX7BmzM9pu0_wv6BXV18LB_b8ZnhA6jhy-ldnr2cKk9tvFo8JY7z7pZcHzOQQcp01VZs1iSOmW8KIssA5LWM19a5yF0enn59VrRR3AYBkAwQmGNc8CZk4IpNQFTKqontNnF1r4Z99XKX3x3ByRPv0hvEtGj7oJfxsk0mZHQ6hScE_U1ioMzKgXGQs9OCExPISPZ9Z5kzaLdZG2d1WyBm1WV1es6Kwu66DfiQGm6Kto8ZwdBc1ZXNa7zdl2267IoKFvIDU1pkdLVelXkVUaXWdamdVW1nK9WpeCC5CkOTKpleM1LY7uFdG7EzYpWZVEtFOOoXBzRlHImvqAOLfHj40-75JlQGga33UQn4GPnSJ4q6by7sXnpVRzxAfJMiv1c-ffMYulg1CyOfvPmQA6NMI_EuzE5LUarNr33x_gcaUNo00nfj3wpzHC1rr87WMzcEdpckz9t6B8BAAD__yNtzso">