Re: RISC-V glibc port, v5

[Palmer Dabbelt <palmer at dabbelt dot com>]

On Thu, 25 Jan 2018 10:37:32 PST (-0800), joseph@codesourcery.com wrote:
> On Thu, 25 Jan 2018, Palmer Dabbelt wrote:
>
> > > I don't approve of the patch series having an inconsistent message about
> > > the status of RV32 support.  Either RV32 is supported by the glibc port,
> > > possibly with a caveat in README like those for i[4567]86-*-gnu and
> > > hppa-*-linux-gnu (the latter of which caveats should be removed...),
> > > referring to kernel issues, and is built by build-many-glibcs.py, etc., or
> > > it's not, in which case you should submit a cleanly RV64-only port, no
> > > RV32 sysdeps directories or conditionals, with a view to possibly adding
> > > RV32 later (with a GLIBC_2.28 or later minimum symbol version for RV32 in
> > > that case).
> >
> > I think the best thing to do here would be to remove the RV32 ABI lists and
> > target it for 2.28.  I don't mind removing the rv32 code as well, I don't
> > think it's that tightly coupled to the rv64 code.
>
> If you want to remove RV32, go ahead with that (including removing rv32
> sysdeps directories, including removing anything in other files in the
> port that only gets built for rv32 such as the dynamic linker names, ABI
> handling in Makefile etc.).  *All* ABI lists would then go in the rv64
> directory (in that it would no longer be possible to share any ABI
> baselines with rv32, if rv32 uses GLIBC_2.28 or later minimum symbol
> version but rv64 uses GLIBC_2.27).  And send a port version 6 as soon as
> possible (e.g. tomorrow).

Makes sense.  I've already proceeded down that path, and I think we're pretty 
close.

> Likewise, if you decide not to support soft-float (though I really
> wouldn't expect soft-float to have the testing time problem you describe,
> and I think there are only a few bits of code that are actually
> conditional on soft-float rather than soft-float-ABI).

We're going to try to get the soft float test suite through, Darius has it 
running.

> Make sure your build-many-glibcs.py configuration builds the actually
> supported configurations - and that building those configurations with
> build-many-glibcs.py does actually work.  Given that GCC expects to build
> both RV32 and RV64 multilibs, it's possible you'll need two separate GCC
> builds (one for each ABI), using --disable-multilib, and will only be able
> to reduce to a single GCC build once you support RV32 in glibc.

Sorry I screwed that up this time, I've got it running again.