This is the mail archive of the
mailing list for the glibc project.
Re: RISC-V glibc Port v1
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: joseph at codesourcery dot com
- Cc: libc-alpha at sourceware dot org
- Cc: Andrew Waterman <andrew at sifive dot com>
- Cc: patches at groups dot riscv dot org
- Cc: Darius Rad <darius at bluespec dot com>
- Date: Wed, 14 Jun 2017 16:44:02 -0700 (PDT)
- Subject: Re: RISC-V glibc Port v1
- Authentication-results: sourceware.org; auth=none
On Wed, 14 Jun 2017 13:41:21 PDT (-0700), firstname.lastname@example.org 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
>> * 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
>> 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
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
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.