This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RISC-V glibc Port v1

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]