Re: RISC-V glibc Port v1

[Palmer Dabbelt <palmer at dabbelt dot com>]

On Wed, 14 Jun 2017 13:41:21 PDT (-0700), joseph@codesourcery.com wrote:
> 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>.

OK, that makes sense.

>> > * 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.

Ya, I love having tests -- the only reason I didn't run glibc tests is because
I didn't know about them.  We've got some regression scripts for the
'riscv-gnu-toolchain' repository (a super-repository containing tagged commits
of binutils, gcc, and glibc as well as some build scripts) that I run, I'll get
the tests to run and then add them to that list.

> 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.

OK, I'll look into that.  We've yet to provide any public infrastructure, but
running the tests manually on everyone's commits is becoming enough of a pain
that it might be worth it.