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

[Maciej W. Rozycki]

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.

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

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

  Maciej