GCC compiles code with --march=rv64gc but get c.zext.b that's in zcb extension

[Ye-Jinhong]

description
I compiles the tool with configuration:

1. gcc 13.2

./configure --prefix=`pwd`/installed_tools --with-arch=rv64gc_zba_zbb_zbc_zbs_zicsr_zifencei_zicond_zcb_zfa --with-abi=lp64d

and 2. gcc 14.0

./configure --prefix=`pwd`/installed_tools --with-arch=rv64gc_zba_zbb_zbc_zbs_zicsr_zifencei_zicond_zcb_zfa --with-abi=lp64d --with-gcc-src=`pwd`/gcc-master --with-newlib-src=`pwd`/newlib-master

more details in #1448 .
However, when I compile the coremark with -march=rv64gc, unexpected instructions in zcb was generated like c.zext.b/h.

   138c6:	9fe9                	zext.h	a5,a5

By the way, does c.zext will dump as zext?

[TommyMurphyTM1234]

Is the zext instruction appearing in a disassembly of library code by any chance? If so, then I suspect that the issue is that your toolchain doesn't have a multilib specifically for rv64gc/lp64d so it links the toolchain default libraries for rv64gc_zba_zbb_zbc_zbs_zicsr_zifencei_zicond_zcb_zfa/lp64d. This may be a bug in itself because I don't think that it should do that - but I don't really understand the multilib matching logic that was added last year and I'm always wary of letting the toolchain take care of this rather than ensuring that I build all necessary multilibs explicitly.

Or, come to think of it, maybe those matching rules are irrelevant since I think it was always the case that if an appropriate multilib wasn't available then the fallback was to try to just link the toolchain default libs. This is/was a common source of confusion especially when it led to rv32 vs rv64 mismatches at link time. For example:

• ABI Mismatch Error | Unable to link for RV32I_ZICSR with ilp32 ABI #1296 (comment)

Enabling verbose output when compiling should clarify if this is the case and the wrong libraries are being linked.

You probably want to configure your toolchain with --with-multilib-generator="rv64gc-lp64d--" if you're ever going to compile with -march=rv64gc -mabi=lp64d instead of the toolchain default arch/abi of rv64gc_zba_zbb_zbc_zbs_zicsr_zifencei_zicond_zcb_zfa/lp64d.

By the way, does c.zext will dump as zext?

I don't understand what you're asking here. Please clarify.

[TommyMurphyTM1234]

By the way, does c.zext will dump as zext?

I presume that you're asking why c.zext.h (not c.zext as there is no such instruction as far as I can see) decodes as zext.h?

Are you sure that you're correctly identifying the instruction in your disassembly?

• zext.h:
  • /* Zbb or zbkb instructions. */
  • https://github.com/bminor/binutils-gdb/blob/82475fa2fa916677e4c578b4e3e35b49160656fa/opcodes/riscv-opc.c#L1135-L1138
• c.zext.h:
  • /* ZCB instructions. */
  • https://github.com/bminor/binutils-gdb/blob/82475fa2fa916677e4c578b4e3e35b49160656fa/opcodes/riscv-opc.c#L2066

Unfortunately this decoder doesn't help at the moment - maybe because it doesn't support all relevant extension yet:

• https://luplab.cs.ucdavis.edu/2022/06/03/rvcodec-js.html
  • https://luplab.gitlab.io/rvcodecjs/#q=9fe9&abi=false&isa=AUTO

[Ye-Jinhong]

Thank you @TommyMurphyTM1234 , I understand. But when I build multilib following your step using make linux:

You probably want to configure your toolchain with --with-multilib-generator="rv64gc-lp64d--" if you're ever going to compile with -march=rv64gc -mabi=lp64d instead of the toolchain default arch/abi of rv64gc_zba_zbb_zbc_zbs_zicsr_zifencei_zicond_zcb_zfa/lp64d.

errors coming:

In file included from /home/yejinhong/hppa/riscv-multilib/sysroot/usr/include/features.h:527,
                 from /home/yejinhong/hppa/riscv-multilib/sysroot/usr/include/bits/libc-header-start.h:33,
                 from /home/yejinhong/hppa/riscv-multilib/sysroot/usr/include/stdio.h:28,
                 from ../../../../.././gcc/libgcc/../gcc/tsystem.h:87,
                 from ../../../../.././gcc/libgcc/libgcc2.c:27:
/home/yejinhong/hppa/riscv-multilib/sysroot/usr/include/gnu/stubs.h:8:11: fatal error: gnu/stubs-ilp32.h: No such file or directory
    8 | # include <gnu/stubs-ilp32.h>
      |           ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [Makefile:501: _ashldi3.o] Error 1
make[5]: Leaving directory '/home/yejinhong/hppa/riscv-gnu-toolchain/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/lib32/ilp32/libgcc'
make[4]: *** [Makefile:1214: multi-do] Error 1
make[4]: Leaving directory '/home/yejinhong/hppa/riscv-gnu-toolchain/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/libgcc'
make[3]: *** [Makefile:127: all-multi] Error 2
make[3]: *** Waiting for unfinished jobs....
In file included from ../../.././gcc/libgcc/unwind-dw2.c:410:
./md-unwind-support.h: In function 'riscv_fallback_frame_state':
./md-unwind-support.h:67:6: warning: assignment to 'struct sigcontext *' from incompatible pointer type 'mcontext_t *' [-Wincompatible-pointer-types]
   67 |   sc = &rt_->uc.uc_mcontext;
      |      ^
make[3]: Leaving directory '/home/yejinhong/hppa/riscv-gnu-toolchain/build-gcc-linux-stage2/riscv64-unknown-linux-gnu/libgcc'
make[2]: *** [Makefile:13274: all-target-libgcc] Error 2
make[2]: Leaving directory '/home/yejinhong/hppa/riscv-gnu-toolchain/build-gcc-linux-stage2'
make[1]: *** [Makefile:1039: all] Error 2
make[1]: Leaving directory '/home/yejinhong/hppa/riscv-gnu-toolchain/build-gcc-linux-stage2'
make: *** [Makefile:492: stamps/build-gcc-linux-stage2] Error 2

My configure is

./configure --prefix=/home/yejinhong/hppa/riscv-multilib --with-multilib-generator="rv64gc_zicsr_zifencei-lp64d--;rv64gc_zicond_zicsr_zifencei-lp64d--;rv64gc_zicsr_zifencei_zba_zbb_zbc_zbs-lp64d--;rv64gc_zicsr_zifencei_zba_zbb_zbc_zbs_zicond-lp64d--;rv64gc_zicsr_zifencei_zba_zbb_zbc_zbs_zicond_zcb_zfa-lp64d--;"

Whatever I do such as make clean -> make newlib -> make distclean, finally make linux will cause error.(follows #1445)

So how can I build multilib? OR is there anything wrong besides multilib building?

[TommyMurphyTM1234]

Thank you @TommyMurphyTM1234 , I understand. But when I build multilib following your step using make linux:

I assumed that you were using a bare-metal toolchain. --with-multilib-generator only works with the bare-metal toolchain. It doesn't work with the Linux toolchain.

• https://github.com/riscv-collab/riscv-gnu-toolchain?tab=readme-ov-file#build-with-customized-multi-lib-configure

So how can I build multilib? OR is there anything wrong besides multilib building?

Unfortunately I haven't found a way to build the Linux toolchain with a custom set of multilibs ever since the approach of editing gcc/config/riscv/t-linux-multilib stopped working a while ago.

• How to build Linux toolchain with custom set of multilibs? #1445
• How does the multilib selection mechanism work these days? #1354

In any case there's another fundamental problem with Linux toolchain multilibs - only one multilib per XLEN/abi can be bundled:

• Linux glibc multilib issue with different "march" #1393

All I can suggest is that you build a separate Linux toolchain for each arch/abi that you need specifying them via configure --with-arch=... --with-abi=....

[TommyMurphyTM1234]

YES, and I am confused why c.zext.h will decoded as zext.h.

You'll probably need to ask about this upstream in the Binutils project.

• https://www.gnu.org/software/binutils/

[Ye-Jinhong]

Thank you @TommyMurphyTM1234 , I build toolchains separately, and it works well. I then close this issue.

[kito-cheng]

YES, and I am confused why c.zext.h will decoded as zext.h.

Compressed instruction are disassemble into non compressed form by default, and this can be disabled by pass -M no-aliases to objdump

[TommyMurphyTM1234]

YES, and I am confused why c.zext.h will decoded as zext.h.

You'll probably need to ask about this upstream in the Binutils project.

• https://www.gnu.org/software/binutils/

Sincere apologies but I inadvertently deleted a post from @Ye-Jinhong earlier - the one that I was replying to here and quoted in part. Sorry about that @Ye-Jinhong.

[TommyMurphyTM1234]

YES, and I am confused why c.zext.h will decoded as zext.h.

Compressed instruction are disassemble into non compressed form by default, and this can be disabled by pass -M no-aliases to objdump

Thanks for that @kito-cheng - I, for one, wasn't aware of that! 👍