[Bug target/90419] RISCV --with-multilib-list support is somewhat incomplete

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90419

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
For cross compilers, --enable-multilib gives a decent selection of multilib
targets.

For native compilers, we don't have linux kernel support to run 32-bit code on
64-bit parts.  Also, I'm not aware of any hardware that has the hardware
support necessary to run 32-bit code on 64-bit parts, which makes the linux
kernel support somewhat of a moot problem.  So, currently, there is no use for
building native multilib compilers.

There is however a problem that the RISC-V ABI requires that libraries go in
very specific places, e.g. /lib64/lp64d for the default linux ABI.  In order to
get the library paths correct in a native linux system compiler that will be
installed into /usr/bin, one must build gcc multilib, and one must
simultaneously disable the multilibs that won't work.  This is what
--with-multilib-list is for.  If you configure --enable-multilib
--with-multilib-list=lp64d then you will get the correct result.  This is how
Fedora configures their RISC-V compilers for instance.

Supporting more than one ABI in --with-multilib-list is a major project. 
Currently this is implemented via sed scripts, but the fact that we have two
interrelated options here -march and -mabi means that this gets very
complicated very quickly.  I looked at this and gave up, and decided that
support for only one ABI at a time was practical.  If you want more than one
ABI, then this is an enhancement request not a bug, and it is unclear when or
if this will get fixed.

32-bit glibc support exists but has not been merged into the glibc tree yet. 
This was pending on the y2038 patches.  Currently all 32-bit linux targets use
a 32-bit time_t that will overflow in 2038.  This requires an unfortunate ABI
break to fix.  As RISC-V is a new target, we were waiting for the y2038
infrastructure patches to go into first (both linux kernel and glibc), so that
we could avoid an ABI break shortly after contributing the 32-bit RISC-V port. 
I think all of the infrastructure patches are in now, but likely need some
testing.  I just recently reported a glibc bug due to these changes, which
turned out to actually be a linux kernel bug.  Anyways, the main problem now is
finding a volunteer to pick up the 32-bit RISC-V glibc work and finish it. 
Meanwhile, the 32-bit glibc patches are available as a patch set that was sent
to the libc-alpha mailing list last year, and as patches on the
riscv-glibc-2.29 branch in the github.com/riscv/riscv-glibc tree.  This branch
is used by and known to work with the riscv/meta-riscv open-embedded tree.

I agree the current situation is not ideal, but RISC-V is a very new target
that isn't fully fleshed out yet, and the situation will get better in a year
or two.  This is mostly a user education problem at the moment.

By the way, there is already a gentoo RISC-V port.  A co-worker Palmer Dabbelt
did one.  I don't know anything about gentoo though, and I haven't tried using
it.  So you would have to ask him about it if interested.