Wrong addition of multilib rv64gcv-lp64d for glibc

[majin2020]

#PR1657

Hi, I noticed that we added rv64gcv-lp64d for the multilib of glibc. However, this is not suitable for the current multilib rules of the Linux toolchain, as the multilib path search is based on ABI. This leads to a duplication of rv64gcv-lp64d and rv64gc-lp64d, with rv64gcv-lp64d overriding rv64gc-lp64d (resulting in only rv64gcv-lp64d multilib existing). This could cause unexpected errors, such as illegal instructions.

@pz9115 @kito-cheng @TommyMurphyTM1234

[majin2020]

A simple example:

Build a linux tool chain with --with-cmodel=medany --enable-multilib --with-arch=rv64gc --with-abi=lp64d, then the arch in sysroot/usr/lib64/lp64d/crt1.o includes the extension V.

$ riscv64-unknown-linux-gnu-readelf -A sysroot/usr/lib64/lp64d/crt1.o
Attribute Section: riscv
File Attributes
  Tag_RISCV_stack_align: 16-bytes
  Tag_RISCV_arch: "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0"

[TommyMurphyTM1234]

Is this effectively a duplicate of this issue?

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

As mentioned in that thread the issue is one that may already be noted but probably should be dealt with in the upstream GCC project where all development/enhancement/bug fixing of the tools, including to RISC-V target support, is done these days.

• Linux glibc multilib issue with different "march" #1393 (comment)
• Linux glibc multilib issue with different "march" #1393 (comment)

[pz9115]

Thanks for your report, I will check up this.

[pz9115]

Maybe we should have an additional library combination for sysroot/usr/lib64, corresponding to both -march and -mabi, like rv64gc-lp64, rv64gcv-lp64d, and rv64gc-lp64d. I'm not sure if this is a better solution here, but let me prepare a patch to see what the upstream opinion on this is. Or a new vector ABI lp64v may a better choice.

[TommyMurphyTM1234]

Maybe we should have an additional library combination for sysroot/usr/lib64, corresponding to both -march and -mabi

Are there other/bigger issues with the Linux toolchain sysroot?

• The executable files in the sysroot/sbin and sysroot/usr/bin directories of the multilib toolchain are random #1270

[majin2020]

Maybe we should have an additional library combination for sysroot/usr/lib64, corresponding to both -march and -mabi, like rv64gc-lp64, rv64gcv-lp64d, and rv64gc-lp64d. I'm not sure if this is a better solution here, but let me prepare a patch to see what the upstream opinion on this is. Or a new vector ABI lp64v may a better choice.

I tend to prefer using the architecture to search for paths, as newlib does, instead of the ABI, to resolve this issue.

[TommyMurphyTM1234]

As I suggested earlier, and as also suggested by this comment from @pz9115:

• Wrong addition of multilib rv64gcv-lp64d for glibc #1673 (comment)

isn't this something that needs to be dealt with, discussed, addressed, upstream in the main GCC (and/or Binutils?) repo?

@pz9115, did you make any progress on this?

let me prepare a patch to see what the upstream opinion on this is.