Multilib compiler triple does not match documentation

[asb]

The README states "The multilib compiler will have the prefix riscv-unknown-linux-gnu-, rather than the usual prefix (riscv32-... or riscv64-...)." After ./configure --prefix=/path/to/install --enable-multilib; make linux I'm seeing tools built with the riscv64-unknown-linux-gnu prefix.

[jim-wilson]

It looks like this changed 2 years ago. With these two patches
df81277
d36be56
I will have to do a little more research to verify.

It would be possible to fix this by changing the name of the installed compiler, which doesn't have to exactly match the configure tuple. However, given that we have apparently been doing it this way for 2 years, it is probably just better to fix the docs to match the code.

[palmer-dabbelt]

I think it's better to fix the docs.

[asb]

It's the easier fix, but I'm not sure it's the best one. Isn't riscv64-unknown-linux-gnu a fundamentally confusing triple for an rv32/rv64 multilib toolchain?

[palmer-dabbelt]

I think the problem is that based on the existing conventions, there's going to be some confusion somewhere. Since most architectures don't support 64-bit output from their 32-bit targets, if we called it "riscv-" then people would say "where's your 64-bit compiler". The only target that doesn't support 32-bit output from their 64-bit toolchain is ARMv8, and I'd argue that's just because there is no aarch32 compiler ("arm-" is a v7 compiler).

Since all the RISC-V tuples do the same thing, people can just call them whatever they want. We should probably go add a "riscv-* -> riscv32-*" alias in gnuconfig so distros can ship whatever they want, but I don't want to change what we're building here because it'll cause a bunch of headaches for no real gain.

[asb]

I suppose it depends on whether you mentally expand "riscv" to "riscv32" or "riscv??", and whether it really does seem logical to invoke a riscv64 toolchain to build for a strictly riscv32 target. I think Mips ended up with a mips-img-linux-gnu triple for their very multi-libbed toolchain.

Anyway, I was just writing the Clang driver code for pulling multilibs out of an existing gcc install or sysroot and thought I'd double check the intention here.

[jim-wilson]

It is possible to build a multilib riscv32 toolchain. The riscv-gnu-toolchain project does not currently support that, but it would be easy to add. It should be a simple change to the toplevel configure file to add 32-bit multilib lists for 32-bit configure tuples.

The arm-* compilers can emit v8 aarch32 code, which is very similar to v7 code.

The mips-img-linux-gnu target is an interesting example. I hadn't realized that they had changed their naming scheme to drop the 32/64. If wanted to do the same for riscv though, we would need patches for binutils, gdb, gcc, etc. It is simpler to just document how the sources actually work.

If someone wants to name their toolchain riscv-* they are certainly able to do that. The riscv-embed project does this for instance.