[PATCH v5 00/17] glibc port for 32-bit RISC-V (RV32)

[Alistair Francis]

On Mon, Aug 24, 2020 at 11:17 AM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Mon, 24 Aug 2020, Alistair Francis wrote:
>
> > >  Would you be able to see if there is any interesting information in the
> > > respective .out files and/or the overall test log?
> >
> > Yep, see below for the RV32 failure logs:
> >
> > elf/tst-libc_dlvsym.out
> > error: tst-libc_dlvsym.h:103: symbol _sys_errlist not found at any version
> > error: 1 test failures
> >
> > elf/tst-libc_dlvsym-static.out
> > error: tst-libc_dlvsym.h:103: symbol _sys_errlist not found at any version
>
>  Well, we have this in NEWS:
>
> * The deprecated symbols sys_errlist, _sys_errlist, sys_nerr, and _sys_nerr
>   are no longer available to newly linked binaries, and their declarations
>   have been removed from from <stdio.h>.  They are exported solely as
>   compatibility symbols to support old binaries.  All programs should use
>   strerror or strerror_r instead.
>
> so it looks like a test case bug to me; the symbol is expected not to be
> there given that we have no compatibility with previous library versions
> to take care of.  Not a showstopper for RV32 inclusion IMO.

Yep, it looks like this is a test failure. I'll send a patch out now with a fix.

>
> > io/tst-lockf.out
> > error: subprocess failed: lockf
> > error:   unexpected output from subprocess
> > tst-lockf.c:49: numeric comparison failure
> >    left: 0 (0x0); from: lockf (temp_fd, F_TEST, 1024)
> >   right: -1 (0xffffffff); from: -1
> > error: 2 test failures
>
>  This might be more interesting to look into further; as `len' is of the
> `off_t' type it would be good to double-check it is correctly handled.

I have fixed this as well, the test is incorrectly calling the lockf()
function (not 64-bit version). I'll send a patch.

With these three fixed we now have the same two failures as RV64 :)

Alistair

>
> > stdlib/tst-strfrom.out
> > Testing in locale: C
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> > Testing in locale: en_US.ISO-8859-1
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> > Testing in locale: en_US.UTF-8
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> >
> > stdlib/tst-strfrom-locale.out
> > Testing in locale: de_DE.UTF-8
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> > Testing in locale: tr_TR.ISO-8859-9
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> > Testing in locale: tr_TR.UTF-8
> > strfromf: got NAN (3), expected -NAN (4)
> > strfromf32: got NAN (3), expected -NAN (4)
> >
> > I'm assuming that stdlib/tst-strfrom and stdlib/tst-strfrom-locale are
> > just related to QEMU FP bugs, as they fail for both RV32 and RV64.
>
>  Agreed, and in any case RV32 does not perform any worse than RV64.  Of
> course it would be good to look into it anyway, but it shouldn't be a
> showstopper for RV32 inclusion IMO.
>
> > > > NOTE: This doesn't include the failing maths tests (that is an issue
> > > > only when running on QEMU) or the PLT issue for RISC-V 32-bit.
> > >
> > >  Ack.  Can you check if the PLT issue has been fixed with
> > > <https://sourceware.org/pipermail/binutils/2020-August/112750.html>?
> >
> > Yes, using the latest binutils with those patches applied seems to fix
> > the PLT failures.
>
>  Good to know, thanks for confirming.  So I guess we can ignore the PLT
> check failure and expect anyone caring about clean results to use most up
> to date binutils once the fix has been included (and until then use the
> patch applied locally).
>
>  I've cc-ed Nelson to give him some incentive to upstream his fix quickly.

Thanks.

Alistair

>
>   Maciej