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

[Alistair Francis]

On Sat, Aug 22, 2020 at 6:04 AM Maciej W. Rozycki <macro@wdc.com> wrote:
>
> On Fri, 21 Aug 2020, Alistair Francis wrote:
>
> > > > This is the current list of tests that fail when running inside QEMU RV32
> > > > system emulation on the 5.4 kernel:
> > > >
> > > > FAIL: elf/tst-libc_dlvsym
> > > > FAIL: elf/tst-libc_dlvsym-static
> > > > FAIL: io/tst-lockf
> > > > FAIL: stdlib/tst-strfrom
> > > > FAIL: stdlib/tst-strfrom-locale
> > >
> > >  How does it compare to RV64 results in a corresponding environment?
> >
> > I just finished running the tests and the RV64 failing tests look like this:
> >
> > FAIL: elf/tst-audit2
> > FAIL: nptl/tst-cancel28
> > FAIL: stdlib/tst-strfrom
> > FAIL: stdlib/tst-strfrom-locale
>
>  Sigh, I hoped the results would be the same, which we could then blame on
> some common issues across RISC-V ports.  I can imagine `tst-lockf' being
> caused by some Linux kernel issue, however `dlvsym' issues likely come
> from our dynamic loader or maybe the static linker.
>
>  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

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

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.

I'll look into the missing _sys_errlist symbol

>
>  NB to save some processing time and have results available sooner you can
> rerun coarse subsets of the test suite if you need to, by removing the
> relevant (or all) .out files from any previous testing and then running:
>
> $ make <args> subdirs="<foo> <bar> ..." check
>
> to limit testing to the subdirectories named, e.g.:
>
> $ make <args> subdirs="elf io" check
>
> (substitute <args> with any other arguments you usually use with testing
> glibc).

Thanks.

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

Alistair

>
>   Maciej