Re: RISC-V glibc Port v1

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 14 Jun 2017, Palmer Dabbelt wrote:

> RISC-V is a modular ISA, and as such there are many ISA variants.  The actual
> number is the Cartesian product of:
> 
>  * RV32I, RV64I: base ISA, which defines the length of GP registers (which we
>    call XLEN).
>  * M or no-M: multiply support or not.
>  * A or no-A: atomic instruction support or not.
>  * none, F, or D: the floating-point format supported, either none, single or
>    double.
>  * C or no-C: compressed instructions support or not.
> 
> In addition to the ISA variants, we support soft, single-hard, and double-hard
> float ABIs on any ISA that includes the required floating-point registers.
> 
> In order to avoid building this huge number of ISA variants we only actively
> support and test the following configurations
> 
>   march=rv32imac/mabi=ilp32
>   march=rv32imafdc/mabi=ilp32d
>   march=rv64imac/mabi=lp64
>   march=rv64imafdc/mabi=lp64d
> 
> for glibc.  I'll add those to the build script, and verify they build with the
> relevant GCC versions.

Well, you are defining dynamic linker names explicitly for RISCV_ABI_FLEN 
== 32, which I assume is the single-hard ABI variants (six dynamic linker 
names).  I think such a variant should either have an error at configure 
time, or be included in the variants built with build-many-glibcs.py, 
rather than having a dynamic linker name defined but not actually being 
built.  Of course it may not be tested very actively, but that's true of 
many variants.

Once the port is in, all the dynamic linker names should be listed at 
<https://sourceware.org/glibc/wiki/ABIList>.

> > * Also include details of the full testsuite results, including execution
> > tests (which build-many-glibcs.py can't run), for all ABI variants again,
> > in the next submission of the port.
> 
> We've just been running the GCC test suite.  I'll take a shot at running the
> glibc test suite as well.

Note that there is an expectation that each release cycle, the 
architecture maintainer should, during the one-month release freeze, run 
the full testsuite for that architecture and report on the results on the 
per-release wiki page (e.g. 
<https://sourceware.org/glibc/wiki/Release/2.25>.  Preferably, failures 
seen should be cleaned up as well rather than just reported on but not 
fixed.

We don't require ports to have buildslaves for the buildbot 
<https://sourceware.org/glibc/wiki/Buildbot>, but if you can contribute 
such buildslaves to test the main variants you care about, and then 
monitor the results for them so that regressions are discovered quickly, 
that's helpful.

-- 
Joseph S. Myers
joseph@codesourcery.com