[gentoo-dev] Re: How to structure our RISC-V support

[Palmer Dabbelt]

On Thu, 06 May 2021 13:01:23 PDT (-0700), dilfridge@g.o wrote:
> Howdy.
>
> I'm sending this not only to the team members on the alias, but also
> to the whole dev list for discussion.
>
> So far I've been trying to support in Gentoo the full risc-v multilib
> directory structure and the ABI sets supported by glibc. According to
> specs this means for riscv64
>
> -mabi=rv64gc -march=lp64d
>   libdir = lib64/lp64d
>   ("hardfloat")
>
> -mabi=rv64imac -march=lp64
>   libdir = lib64/lp64
>   ("softfloat")
>
> and theoretically similar for riscv32 (which just landed in glibc and
> is still broken in qemu-user).
>
> However, this leads to several levels of pain (and I definitely dont
> have time to deal with it myself):
>
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads
> to difficulties in build systems. Right now Qt5 and CMake are still
> somewhat broken (in *Gentoo*).
>
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should
> have for decent Linux support.)
>
> I'm pretty sure these are not the only things, but they are somewhat
> symptomatic.
>
> So, I would like to bring two proposals up for discussion.
>
> 1) We stop caring about anything except rv64gc/lp64d.
> People can still bootstrap other stuff with crossdev etc, but the
> Gentoo tree and the riscv keyword reflect that things work with above
> -mabi and -march settings.

IMO dropping multilib is fine from a "working on real hardware" 
perspective, as that's all anyone is going to have for the forseeable 
future -- at least for the sort of hardware you'd want to run a 
desktop/server style Linux distro on (something like buildroot might be 
interested in other ISA/ABI combos).

That said, it seems like a lot of the distros are punting on multilib 
because of this path issue.  If that's really the worry then I wouldn't 
be opposed to just fixing it in GCC/glibc.  Ideally we'd be able to just 
add paths so we don't break the ABI, but if the ABI we came up with 
really hasn't been used by anyone then I wouldn't be opposed to breaking 
it if it means we can actually get multilib up and running -- we'd have 
to talk with a lot of people for that, though.

In the long run I think we will want multilib to work, as we're likely 
to end up with some ISA extensions that are useful enough to want to 
build general code for but not so useful that everyone has them -- B and 
V, for example.  We're a long way away from having good code gen for V 
(at least for arbitrary code, some special libraries might show up 
sooner), but B is a bit closer and might be amenable to having a system 
built with it.  That may be a bit less interesting for Gentoo, where 
we're building things locally (and there shouldn't be any -bin packages 
on RISC-V yet, we're not getting ports of proprietary stuff yet), but if 
we can be a forcing function to put together a multlib ABI that actually 
works then that's a win for everyone.

> 2) We drop the multilib paths and use "normal" lib64, with additional
> "safety symlinks" (/usr)/lib64/lp64d -> .
> This is what SuSE and (I think) Fedora already does. The symlink
> should be there since "lib64" is NOT an official fallback coded into
> gcc/glibc/binutils; the only fallback present is "lib" ...

IMO we can just fix that one upstream.  If all the distros are going to 
do it anyway then it'd be better to just fix it, there's not a lot of 
sense in forcing everyone to patch these things.  IIUC that one would be 
an ABI-compatible addition, but again we'd need to talk about it in 
GCC/glibc land (and with some other distro folks).

Sorry this is such a mess!