riscv32 wait() problem, qemu or glibc?

riscv32 wait() problem, qemu or glibc?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Hi, 

first of all, sorry for crossposting, but I'm dealing with many moving and 
experimental parts here... 

Situation: riscv32 (ilp32) qemu-user [1] chroot, Linux [2], glibc [3], gcc [4]

The following small program outputs "child exited with status 40", which is 
rather unexpected (it should be 42). Any idea what is going on?

(This is a simplified version of code in a configure test. The test has other 
potential issues [5], but in any case it cant produce useful results on 
riscv32 right now.)

TIA, 
Andreas

====================================
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

main(c, v)
     int c;
     char **v;
{
  pid_t pid, p;
  int s, i, n;

  s = 0;
  pid = fork();
  if (pid == 0)
    exit (42);

  /* wait for the process */
  p = wait(&s);
  if (p != pid)
    exit (255);

  if (WIFEXITED(s))
  {
     int r=WEXITSTATUS(s);
     printf("child exited with status %i\n",r);
  }
}
====================================


[1] qemu built from git master, Sep 12, 2020 16:30:37 EEST
[2] host kernel is 5.8.8
[3] glibc-2.32 with the rv32 patch series backported from master
[4] (Gentoo 10.2.0-r1 p2)
[5] https://lists.gnu.org/archive/html/bug-bash/2020-09/msg00033.html

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: riscv32 wait() problem, qemu or glibc?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 7270 bytes --]

Not sure if this helps in any way, but I tried if the problem is specific to 
the return value 42. Leading to more confusing results... though this looks 
more like an emulator problem than a libc problem to me now.

Happy to debug further, but with limited ideas on how to proceed.

(riscv-ilp32 chroot) farino /tmp # ./wait-test 
child wants to return 34 (0x22), parent received 32 (0x20), difference -2
child wants to return 35 (0x23), parent received 33 (0x21), difference -2
child wants to return 36 (0x24), parent received 34 (0x22), difference -2
child wants to return 37 (0x25), parent received 35 (0x23), difference -2
child wants to return 38 (0x26), parent received 36 (0x24), difference -2
child wants to return 39 (0x27), parent received 37 (0x25), difference -2
child wants to return 40 (0x28), parent received 38 (0x26), difference -2
child wants to return 41 (0x29), parent received 39 (0x27), difference -2
child wants to return 42 (0x2A), parent received 40 (0x28), difference -2
child wants to return 43 (0x2B), parent received 41 (0x29), difference -2
child wants to return 44 (0x2C), parent received 42 (0x2A), difference -2
child wants to return 45 (0x2D), parent received 43 (0x2B), difference -2
child wants to return 46 (0x2E), parent received 44 (0x2C), difference -2
child wants to return 47 (0x2F), parent received 45 (0x2D), difference -2
child wants to return 48 (0x30), parent received 46 (0x2E), difference -2
child wants to return 49 (0x31), parent received 47 (0x2F), difference -2
child wants to return 50 (0x32), parent received 48 (0x30), difference -2
child wants to return 51 (0x33), parent received 49 (0x31), difference -2
child wants to return 52 (0x34), parent received 50 (0x32), difference -2
child wants to return 53 (0x35), parent received 51 (0x33), difference -2
child wants to return 54 (0x36), parent received 52 (0x34), difference -2
child wants to return 55 (0x37), parent received 53 (0x35), difference -2
child wants to return 56 (0x38), parent received 54 (0x36), difference -2
child wants to return 57 (0x39), parent received 55 (0x37), difference -2
child wants to return 58 (0x3A), parent received 56 (0x38), difference -2
child wants to return 59 (0x3B), parent received 57 (0x39), difference -2
child wants to return 60 (0x3C), parent received 58 (0x3A), difference -2
child wants to return 61 (0x3D), parent received 59 (0x3B), difference -2
child wants to return 62 (0x3E), parent received 60 (0x3C), difference -2
child wants to return 63 (0x3F), parent received 61 (0x3D), difference -2
child wants to return 64 (0x40), parent received 62 (0x3E), difference -2
child wants to return 162 (0xA2), parent received 160 (0xA0), difference -2
child wants to return 163 (0xA3), parent received 161 (0xA1), difference -2
child wants to return 164 (0xA4), parent received 162 (0xA2), difference -2
child wants to return 165 (0xA5), parent received 163 (0xA3), difference -2
child wants to return 166 (0xA6), parent received 164 (0xA4), difference -2
child wants to return 167 (0xA7), parent received 165 (0xA5), difference -2
child wants to return 168 (0xA8), parent received 166 (0xA6), difference -2
child wants to return 169 (0xA9), parent received 167 (0xA7), difference -2
child wants to return 170 (0xAA), parent received 168 (0xA8), difference -2
child wants to return 171 (0xAB), parent received 169 (0xA9), difference -2
child wants to return 172 (0xAC), parent received 170 (0xAA), difference -2
child wants to return 173 (0xAD), parent received 171 (0xAB), difference -2
child wants to return 174 (0xAE), parent received 172 (0xAC), difference -2
child wants to return 175 (0xAF), parent received 173 (0xAD), difference -2
child wants to return 176 (0xB0), parent received 174 (0xAE), difference -2
child wants to return 177 (0xB1), parent received 175 (0xAF), difference -2
child wants to return 178 (0xB2), parent received 176 (0xB0), difference -2
child wants to return 179 (0xB3), parent received 177 (0xB1), difference -2
child wants to return 180 (0xB4), parent received 178 (0xB2), difference -2
child wants to return 181 (0xB5), parent received 179 (0xB3), difference -2
child wants to return 182 (0xB6), parent received 180 (0xB4), difference -2
child wants to return 183 (0xB7), parent received 181 (0xB5), difference -2
child wants to return 184 (0xB8), parent received 182 (0xB6), difference -2
child wants to return 185 (0xB9), parent received 183 (0xB7), difference -2
child wants to return 186 (0xBA), parent received 184 (0xB8), difference -2
child wants to return 187 (0xBB), parent received 185 (0xB9), difference -2
child wants to return 188 (0xBC), parent received 186 (0xBA), difference -2
child wants to return 189 (0xBD), parent received 187 (0xBB), difference -2
child wants to return 190 (0xBE), parent received 188 (0xBC), difference -2
child wants to return 191 (0xBF), parent received 189 (0xBD), difference -2
child wants to return 192 (0xC0), parent received 190 (0xBE), difference -2
(riscv-ilp32 chroot) farino /tmp #

===================
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

main(c, v)
     int c;
     char **v;
{
 for(int z=0; z<255; z++){
  pid_t pid, p;
  int s, i, n;

  s = 0;
  pid = fork();
  if (pid == 0)
    exit(z);

  /* wait for the process */
  p = wait(&s);
  if (p != pid)
    exit (255);

  if (WIFEXITED(s))
  {
     int r=WEXITSTATUS(s);
     if (z!=r) {
      printf("child wants to return %i (0x%X), parent received %i (0x%X), 
difference %i\n",z,z,r,r,r-z);
     }
  }
 }
}
===================


Am Montag, 14. September 2020, 11:14:16 EEST schrieb Andreas K. Hüttel:
> Hi,
> 
> first of all, sorry for crossposting, but I'm dealing with many moving and
> experimental parts here...
> 
> Situation: riscv32 (ilp32) qemu-user [1] chroot, Linux [2], glibc [3], gcc
> [4]
> 
> The following small program outputs "child exited with status 40", which is
> rather unexpected (it should be 42). Any idea what is going on?
> 
> (This is a simplified version of code in a configure test. The test has
> other potential issues [5], but in any case it cant produce useful results
> on riscv32 right now.)
> 
> TIA,
> Andreas
> 
> ====================================
> #include <stdlib.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/wait.h>
> 
> main(c, v)
>      int c;
>      char **v;
> {
>   pid_t pid, p;
>   int s, i, n;
> 
>   s = 0;
>   pid = fork();
>   if (pid == 0)
>     exit (42);
> 
>   /* wait for the process */
>   p = wait(&s);
>   if (p != pid)
>     exit (255);
> 
>   if (WIFEXITED(s))
>   {
>      int r=WEXITSTATUS(s);
>      printf("child exited with status %i\n",r);
>   }
> }
> ====================================
> 
> 
> [1] qemu built from git master, Sep 12, 2020 16:30:37 EEST
> [2] host kernel is 5.8.8
> [3] glibc-2.32 with the rv32 patch series backported from master
> [4] (Gentoo 10.2.0-r1 p2)
> [5] https://lists.gnu.org/archive/html/bug-bash/2020-09/msg00033.html


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: riscv32 wait() problem, qemu or glibc?

[Alistair Francis]

On Mon, Sep 14, 2020 at 1:14 AM Andreas K. Hüttel via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi,
>
> first of all, sorry for crossposting, but I'm dealing with many moving and
> experimental parts here...
>
> Situation: riscv32 (ilp32) qemu-user [1] chroot, Linux [2], glibc [3], gcc [4]
>
> The following small program outputs "child exited with status 40", which is
> rather unexpected (it should be 42). Any idea what is going on?
>
> (This is a simplified version of code in a configure test. The test has other
> potential issues [5], but in any case it cant produce useful results on
> riscv32 right now.)
>
> TIA,
> Andreas
>
> ====================================
> #include <stdlib.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <sys/wait.h>
>
> main(c, v)
>      int c;
>      char **v;
> {
>   pid_t pid, p;
>   int s, i, n;
>
>   s = 0;
>   pid = fork();
>   if (pid == 0)
>     exit (42);
>
>   /* wait for the process */
>   p = wait(&s);

The wait() function internally in glibc calls waitid()
(https://github.com/bminor/glibc/blob/master/posix/wait.c#L25)

The waitid() function then does a waitid syscall
(https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/waitid.c#L29)

QEMU has support for waitid()
(https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L8308)
so this should work.

I also don't see any obvious size mismatches.

My guess is that somewhere in QEMU the types don't match what RV32 is
using. It's probably worth printing out the size, alignment and value
of everything at every stage and see what breaks.

AFAIK RV32 linux-user mode is pretty much un-tested. So their might be
all sorts of issues with it unfortunately.

Alistair

>   if (p != pid)
>     exit (255);
>
>   if (WIFEXITED(s))
>   {
>      int r=WEXITSTATUS(s);
>      printf("child exited with status %i\n",r);
>   }
> }
> ====================================
>
>
> [1] qemu built from git master, Sep 12, 2020 16:30:37 EEST
> [2] host kernel is 5.8.8
> [3] glibc-2.32 with the rv32 patch series backported from master
> [4] (Gentoo 10.2.0-r1 p2)
> [5] https://lists.gnu.org/archive/html/bug-bash/2020-09/msg00033.html
>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, qa, toolchain, base-system, perl, libreoffice)

Re: riscv32 wait() problem, qemu or glibc?

[Alistair Francis]

On Wed, Sep 16, 2020 at 2:09 PM Andreas K. Hüttel <dilfridge@gentoo.org> wrote:
>
> > My guess is that somewhere in QEMU the types don't match what RV32 is
> > using. It's probably worth printing out the size, alignment and value
> > of everything at every stage and see what breaks.
>
> Thanks.

Sorry I can't be more helpful. Hopefully one day I will look into it,
but it's not a high priority.

>
> > AFAIK RV32 linux-user mode is pretty much un-tested. So their might be
> > all sorts of issues with it unfortunately.
>
> Would you consider qemu system mode more reliable?

Yes. For RISC-V the softmmu implementations are much more thoroughly tested.

>
> I need to prepare some bootable riscv gentoo images eventually anyway. Might
> as well try a riscv32 one for comparison then if that is more promising.

It would be great to have more distros supporting RV32.

Alistair

>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, qa, toolchain, base-system, perl, libreoffice)

Re: riscv32 wait() problem, qemu or glibc?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

> My guess is that somewhere in QEMU the types don't match what RV32 is
> using. It's probably worth printing out the size, alignment and value
> of everything at every stage and see what breaks.

Thanks.

> AFAIK RV32 linux-user mode is pretty much un-tested. So their might be
> all sorts of issues with it unfortunately.

Would you consider qemu system mode more reliable?

I need to prepare some bootable riscv gentoo images eventually anyway. Might 
as well try a riscv32 one for comparison then if that is more promising.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: riscv32 wait() problem, qemu or glibc?

[Andreas K. Hüttel]

[-- Attachment #1: Type: text/plain, Size: 6676 bytes --]

Am Donnerstag, 17. September 2020, 00:05:10 EEST schrieb Alistair Francis:
> On Wed, Sep 16, 2020 at 2:09 PM Andreas K. Hüttel <dilfridge@gentoo.org> 
wrote:
> > > My guess is that somewhere in QEMU the types don't match what RV32 is
> > > using. It's probably worth printing out the size, alignment and value
> > > of everything at every stage and see what breaks.
> > 
> > Thanks.
> 
> Sorry I can't be more helpful. Hopefully one day I will look into it,
> but it's not a high priority.

No problem at all. I'm mostly going to postpone this now in favour of 
autobuilding bootable images (which needs some non-riscv specific 
preparation). 

Last thing I still did overnight was run the glibc testsuite in quemu-riscv32 
user emulation. The summary is below (and as suspected a bit of a massacre); 
I'll look at the details later sometime. 
If anyone else wants to poke at it, I've tarred up the full glibc build dir 
and uploaded it together with the build log, see
https://dev.gentoo.org/~dilfridge/rv32-testing/

UNSUPPORTED: crypt/cert
FAIL: debug/tst-backtrace4
FAIL: debug/tst-backtrace5
FAIL: debug/tst-backtrace6
FAIL: elf/check-localplt
UNSUPPORTED: elf/tst-dlopen-self-container
UNSUPPORTED: elf/tst-dlopen-tlsmodid-container
XPASS: elf/tst-latepthread
UNSUPPORTED: elf/tst-ldconfig-bad-aux-cache
UNSUPPORTED: elf/tst-ldconfig-ld_so_conf-update
UNSUPPORTED: elf/tst-pldd
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: iconv/tst-iconv_prog
UNSUPPORTED: io/tst-copy_file_range
UNSUPPORTED: io/tst-getcwd-abspath
FAIL: libio/tst-atime
UNSUPPORTED: locale/tst-localedef-path-norm
UNSUPPORTED: localedata/tst-localedef-hardlinks
FAIL: malloc/tst-dynarray-fail
FAIL: malloc/tst-dynarray-fail-mem
FAIL: malloc/tst-interpose-nothread
FAIL: malloc/tst-interpose-static-nothread
FAIL: malloc/tst-interpose-static-thread
FAIL: malloc/tst-interpose-thread
FAIL: malloc/tst-mallocfork2
UNSUPPORTED: malloc/tst-mallocstate
FAIL: math/test-double-j1
FAIL: math/test-double-y0
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
FAIL: math/test-float-asinh
FAIL: math/test-float-cos
FAIL: math/test-float-cosh
FAIL: math/test-float-erfc
FAIL: math/test-float-exp
FAIL: math/test-float-j0
FAIL: math/test-float-j1
FAIL: math/test-float-lgamma
FAIL: math/test-float-sin
FAIL: math/test-float-tgamma
FAIL: math/test-float-y0
FAIL: math/test-float32-asinh
FAIL: math/test-float32-cos
FAIL: math/test-float32-cosh
FAIL: math/test-float32-erfc
FAIL: math/test-float32-exp
FAIL: math/test-float32-j0
FAIL: math/test-float32-j1
FAIL: math/test-float32-lgamma
FAIL: math/test-float32-sin
FAIL: math/test-float32-tgamma
FAIL: math/test-float32-y0
FAIL: math/test-float32x-j1
FAIL: math/test-float32x-y0
FAIL: math/test-float64-j1
FAIL: math/test-float64-y0
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except
UNSUPPORTED: math/test-nearbyint-except-2
FAIL: misc/test-errno-linux
FAIL: misc/tst-clone2
FAIL: misc/tst-clone3
FAIL: misc/tst-gettid-kill
FAIL: misc/tst-glibcsyscalls
FAIL: misc/tst-memfd_create
FAIL: misc/tst-mlock2
UNSUPPORTED: misc/tst-ofdlocks-compat
UNSUPPORTED: misc/tst-pkey
FAIL: misc/tst-sigcontext-get_pc
UNSUPPORTED: misc/tst-ttyname
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
FAIL: nptl/tst-align-clone
FAIL: nptl/tst-cancel-self-canceltype
FAIL: nptl/tst-cancel17
FAIL: nptl/tst-cancel21
FAIL: nptl/tst-cancel21-static
FAIL: nptl/tst-cancel24
FAIL: nptl/tst-cancel24-static
FAIL: nptl/tst-cancelx16
FAIL: nptl/tst-cancelx17
FAIL: nptl/tst-cancelx18
FAIL: nptl/tst-cancelx20
FAIL: nptl/tst-cancelx21
FAIL: nptl/tst-cancelx4
FAIL: nptl/tst-cancelx5
FAIL: nptl/tst-cleanupx4
FAIL: nptl/tst-cond-except
FAIL: nptl/tst-cond24
FAIL: nptl/tst-cond25
FAIL: nptl/tst-getpid1
UNSUPPORTED: nptl/tst-mutexpi5
UNSUPPORTED: nptl/tst-mutexpi5a
UNSUPPORTED: nptl/tst-mutexpi9
FAIL: nptl/tst-oncex3
FAIL: nptl/tst-oncex4
UNSUPPORTED: nptl/tst-pthread-getattr
FAIL: nptl/tst-robust-fork
FAIL: nptl/tst-robust1
FAIL: nptl/tst-robust2
FAIL: nptl/tst-robust3
FAIL: nptl/tst-robust4
FAIL: nptl/tst-robust5
FAIL: nptl/tst-robust6
FAIL: nptl/tst-robust7
FAIL: nptl/tst-robust8
FAIL: nptl/tst-robust9
XPASS: nptl/tst-stack4
UNSUPPORTED: nss/tst-nss-db-endgrent
UNSUPPORTED: nss/tst-nss-db-endpwent
UNSUPPORTED: nss/tst-nss-files-alias-leak
UNSUPPORTED: nss/tst-nss-files-alias-truncated
UNSUPPORTED: nss/tst-nss-files-hosts-erange
UNSUPPORTED: nss/tst-nss-files-hosts-getent
UNSUPPORTED: nss/tst-nss-files-hosts-long
UNSUPPORTED: nss/tst-nss-test3
FAIL: posix/test-errno
FAIL: posix/tst-fexecve
UNSUPPORTED: posix/tst-glob_lstat_compat
FAIL: posix/tst-posix_spawn-setsid
FAIL: posix/tst-spawn2
FAIL: posix/tst-spawn4
UNSUPPORTED: posix/tst-spawn4-compat
UNSUPPORTED: posix/tst-sysconf-empty-chroot
FAIL: posix/tst-wait4
UNSUPPORTED: resolv/tst-p_secstodate
UNSUPPORTED: resolv/tst-resolv-res_init
UNSUPPORTED: resolv/tst-resolv-res_init-thread
UNSUPPORTED: resolv/tst-resolv-threads
FAIL: rt/tst-aio4
FAIL: rt/tst-mqueue3
FAIL: rt/tst-mqueue5
FAIL: rt/tst-mqueue6
FAIL: rt/tst-mqueue8x
FAIL: stdio-common/tst-vfprintf-width-prec
FAIL: stdio-common/tst-vfprintf-width-prec-mem
UNSUPPORTED: stdlib/tst-system
UNSUPPORTED: string/tst-strerror
UNSUPPORTED: string/tst-strsignal
XPASS: support/tst-support_descriptors
FAIL: sysvipc/test-sysvmsg
FAIL: sysvipc/test-sysvsem
Summary of test results:
     95 FAIL
   3971 PASS
     48 UNSUPPORTED
     17 XFAIL
      5 XPASS
make[1]: *** [Makefile:634: tests] Error 1







> 
> > > AFAIK RV32 linux-user mode is pretty much un-tested. So their might be
> > > all sorts of issues with it unfortunately.
> > 
> > Would you consider qemu system mode more reliable?
> 
> Yes. For RISC-V the softmmu implementations are much more thoroughly tested.
> > I need to prepare some bootable riscv gentoo images eventually anyway.
> > Might as well try a riscv32 one for comparison then if that is more
> > promising.
> It would be great to have more distros supporting RV32.
> 
> Alistair
> 
> > --
> > Andreas K. Hüttel
> > dilfridge@gentoo.org
> > Gentoo Linux developer
> > (council, qa, toolchain, base-system, perl, libreoffice)


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: riscv32 wait() problem, qemu or glibc?

[Alistair Francis]

On Thu, Sep 17, 2020 at 3:16 AM Andreas K. Hüttel <dilfridge@gentoo.org> wrote:
>
> Am Donnerstag, 17. September 2020, 00:05:10 EEST schrieb Alistair Francis:
> > On Wed, Sep 16, 2020 at 2:09 PM Andreas K. Hüttel <dilfridge@gentoo.org>
> wrote:
> > > > My guess is that somewhere in QEMU the types don't match what RV32 is
> > > > using. It's probably worth printing out the size, alignment and value
> > > > of everything at every stage and see what breaks.
> > >
> > > Thanks.
> >
> > Sorry I can't be more helpful. Hopefully one day I will look into it,
> > but it's not a high priority.
>
> No problem at all. I'm mostly going to postpone this now in favour of
> autobuilding bootable images (which needs some non-riscv specific
> preparation).
>
> Last thing I still did overnight was run the glibc testsuite in quemu-riscv32
> user emulation. The summary is below (and as suspected a bit of a massacre);
> I'll look at the details later sometime.
> If anyone else wants to poke at it, I've tarred up the full glibc build dir
> and uploaded it together with the build log, see
> https://dev.gentoo.org/~dilfridge/rv32-testing/
>
> UNSUPPORTED: crypt/cert
> FAIL: debug/tst-backtrace4
> FAIL: debug/tst-backtrace5
> FAIL: debug/tst-backtrace6
> FAIL: elf/check-localplt
> UNSUPPORTED: elf/tst-dlopen-self-container
> UNSUPPORTED: elf/tst-dlopen-tlsmodid-container
> XPASS: elf/tst-latepthread
> UNSUPPORTED: elf/tst-ldconfig-bad-aux-cache
> UNSUPPORTED: elf/tst-ldconfig-ld_so_conf-update
> UNSUPPORTED: elf/tst-pldd
> XPASS: elf/tst-protected1a
> XPASS: elf/tst-protected1b
> FAIL: iconv/tst-iconv_prog
> UNSUPPORTED: io/tst-copy_file_range
> UNSUPPORTED: io/tst-getcwd-abspath
> FAIL: libio/tst-atime
> UNSUPPORTED: locale/tst-localedef-path-norm
> UNSUPPORTED: localedata/tst-localedef-hardlinks
> FAIL: malloc/tst-dynarray-fail
> FAIL: malloc/tst-dynarray-fail-mem
> FAIL: malloc/tst-interpose-nothread
> FAIL: malloc/tst-interpose-static-nothread
> FAIL: malloc/tst-interpose-static-thread
> FAIL: malloc/tst-interpose-thread
> FAIL: malloc/tst-mallocfork2
> UNSUPPORTED: malloc/tst-mallocstate
> FAIL: math/test-double-j1
> FAIL: math/test-double-y0
> UNSUPPORTED: math/test-fesetexcept-traps
> UNSUPPORTED: math/test-fexcept-traps
> FAIL: math/test-float-asinh
> FAIL: math/test-float-cos
> FAIL: math/test-float-cosh
> FAIL: math/test-float-erfc
> FAIL: math/test-float-exp
> FAIL: math/test-float-j0
> FAIL: math/test-float-j1
> FAIL: math/test-float-lgamma
> FAIL: math/test-float-sin
> FAIL: math/test-float-tgamma
> FAIL: math/test-float-y0
> FAIL: math/test-float32-asinh
> FAIL: math/test-float32-cos
> FAIL: math/test-float32-cosh
> FAIL: math/test-float32-erfc
> FAIL: math/test-float32-exp
> FAIL: math/test-float32-j0
> FAIL: math/test-float32-j1
> FAIL: math/test-float32-lgamma
> FAIL: math/test-float32-sin
> FAIL: math/test-float32-tgamma
> FAIL: math/test-float32-y0
> FAIL: math/test-float32x-j1
> FAIL: math/test-float32x-y0
> FAIL: math/test-float64-j1
> FAIL: math/test-float64-y0
> UNSUPPORTED: math/test-matherr
> UNSUPPORTED: math/test-matherr-2
> UNSUPPORTED: math/test-nearbyint-except
> UNSUPPORTED: math/test-nearbyint-except-2
> FAIL: misc/test-errno-linux
> FAIL: misc/tst-clone2
> FAIL: misc/tst-clone3
> FAIL: misc/tst-gettid-kill
> FAIL: misc/tst-glibcsyscalls
> FAIL: misc/tst-memfd_create
> FAIL: misc/tst-mlock2
> UNSUPPORTED: misc/tst-ofdlocks-compat
> UNSUPPORTED: misc/tst-pkey
> FAIL: misc/tst-sigcontext-get_pc
> UNSUPPORTED: misc/tst-ttyname
> UNSUPPORTED: nptl/test-cond-printers
> UNSUPPORTED: nptl/test-condattr-printers
> UNSUPPORTED: nptl/test-mutex-printers
> UNSUPPORTED: nptl/test-mutexattr-printers
> UNSUPPORTED: nptl/test-rwlock-printers
> UNSUPPORTED: nptl/test-rwlockattr-printers
> FAIL: nptl/tst-align-clone
> FAIL: nptl/tst-cancel-self-canceltype
> FAIL: nptl/tst-cancel17
> FAIL: nptl/tst-cancel21
> FAIL: nptl/tst-cancel21-static
> FAIL: nptl/tst-cancel24
> FAIL: nptl/tst-cancel24-static
> FAIL: nptl/tst-cancelx16
> FAIL: nptl/tst-cancelx17
> FAIL: nptl/tst-cancelx18
> FAIL: nptl/tst-cancelx20
> FAIL: nptl/tst-cancelx21
> FAIL: nptl/tst-cancelx4
> FAIL: nptl/tst-cancelx5
> FAIL: nptl/tst-cleanupx4
> FAIL: nptl/tst-cond-except
> FAIL: nptl/tst-cond24
> FAIL: nptl/tst-cond25
> FAIL: nptl/tst-getpid1
> UNSUPPORTED: nptl/tst-mutexpi5
> UNSUPPORTED: nptl/tst-mutexpi5a
> UNSUPPORTED: nptl/tst-mutexpi9
> FAIL: nptl/tst-oncex3
> FAIL: nptl/tst-oncex4
> UNSUPPORTED: nptl/tst-pthread-getattr
> FAIL: nptl/tst-robust-fork
> FAIL: nptl/tst-robust1
> FAIL: nptl/tst-robust2
> FAIL: nptl/tst-robust3
> FAIL: nptl/tst-robust4
> FAIL: nptl/tst-robust5
> FAIL: nptl/tst-robust6
> FAIL: nptl/tst-robust7
> FAIL: nptl/tst-robust8
> FAIL: nptl/tst-robust9
> XPASS: nptl/tst-stack4
> UNSUPPORTED: nss/tst-nss-db-endgrent
> UNSUPPORTED: nss/tst-nss-db-endpwent
> UNSUPPORTED: nss/tst-nss-files-alias-leak
> UNSUPPORTED: nss/tst-nss-files-alias-truncated
> UNSUPPORTED: nss/tst-nss-files-hosts-erange
> UNSUPPORTED: nss/tst-nss-files-hosts-getent
> UNSUPPORTED: nss/tst-nss-files-hosts-long
> UNSUPPORTED: nss/tst-nss-test3
> FAIL: posix/test-errno
> FAIL: posix/tst-fexecve
> UNSUPPORTED: posix/tst-glob_lstat_compat
> FAIL: posix/tst-posix_spawn-setsid
> FAIL: posix/tst-spawn2
> FAIL: posix/tst-spawn4
> UNSUPPORTED: posix/tst-spawn4-compat
> UNSUPPORTED: posix/tst-sysconf-empty-chroot
> FAIL: posix/tst-wait4
> UNSUPPORTED: resolv/tst-p_secstodate
> UNSUPPORTED: resolv/tst-resolv-res_init
> UNSUPPORTED: resolv/tst-resolv-res_init-thread
> UNSUPPORTED: resolv/tst-resolv-threads
> FAIL: rt/tst-aio4
> FAIL: rt/tst-mqueue3
> FAIL: rt/tst-mqueue5
> FAIL: rt/tst-mqueue6
> FAIL: rt/tst-mqueue8x
> FAIL: stdio-common/tst-vfprintf-width-prec
> FAIL: stdio-common/tst-vfprintf-width-prec-mem
> UNSUPPORTED: stdlib/tst-system
> UNSUPPORTED: string/tst-strerror
> UNSUPPORTED: string/tst-strsignal
> XPASS: support/tst-support_descriptors
> FAIL: sysvipc/test-sysvmsg
> FAIL: sysvipc/test-sysvsem
> Summary of test results:
>      95 FAIL
>    3971 PASS
>      48 UNSUPPORTED
>      17 XFAIL
>       5 XPASS
> make[1]: *** [Makefile:634: tests] Error 1

That's actually not too bad. A lot of those are grouped, so fixing one
test should fix a few. Some of them are probably because QEMU is
missing the new syscall.

Some math failures occur in softmmu as well. The guess is that it's
due to bugs in QEMUs float, but I haven't investigated yet.

Alistair

>
>
>
>
>
>
>
> >
> > > > AFAIK RV32 linux-user mode is pretty much un-tested. So their might be
> > > > all sorts of issues with it unfortunately.
> > >
> > > Would you consider qemu system mode more reliable?
> >
> > Yes. For RISC-V the softmmu implementations are much more thoroughly tested.
> > > I need to prepare some bootable riscv gentoo images eventually anyway.
> > > Might as well try a riscv32 one for comparison then if that is more
> > > promising.
> > It would be great to have more distros supporting RV32.
> >
> > Alistair
> >
> > > --
> > > Andreas K. Hüttel
> > > dilfridge@gentoo.org
> > > Gentoo Linux developer
> > > (council, qa, toolchain, base-system, perl, libreoffice)
>
>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, qa, toolchain, base-system, perl, libreoffice)

Re: riscv32 wait() problem, qemu or glibc?

[Qemu devel]

[-- Attachment #1: Type: text/html, Size: 7661 bytes --]