Re: riscv32, qemu-user: semi-functional, what goes wrong?

[Andreas K. Huettel]

Am Dienstag, 12. September 2023, 21:55:13 CEST schrieb Chet Ramey:
> On 8/31/23 7:02 PM, Andreas K. Huettel wrote:
> > Dear all,
> > 
> > I'm trying to get qemu usermode emulation of riscv32 working.
> > I managed to cross-build a linux system, and have it mostly rebuild itself
> > (including gcc 3-phase bootstrap), however, something is broken in bash.
> 
> Is there anything wrong beyond these failed tests? Can you run it
> interactively?
> 

I wanted to start with the tests as some sort of baseline first,
since the symptoms are confusing and I dont even know yet which
piece of software is broken (my bet is on qemu-riscv32 though).

Situation: systemd-nspawn, with a static (x86-64) qemu-riscv32 binary, 
registered with the kernel to handle riscv32 elf files.[1]
Toolchain, glibc, bash, system originally cross-compiled from x86-64;
then I re-built as much in the chroot "natively" using Gentoo's mechanisms
as possible. Bash runs interactively *mostly* fine.

riscv32 ~ # file /bin/bash
/bin/bash: ELF 32-bit LSB pie executable, UCB RISC-V, RVC, double-float ABI, 
version 1 (SYSV), dynamically linked, interpreter 
/lib/ld-linux-riscv32-ilp32d.so.1, for GNU/Linux 5.4.0, stripped

However:
* Something seems wrong in the signal handling (?):
--- our package manager (bash/python combo, there bash) hangs reproducibly at 
one point.
--- when I run a console program and try to background it with ctl-z, it hangs
    (maybe only the first time, not sure)
    repeated ctl-c gets me back to the shell, then the program is in the 
background

riscv32 ~ # python
Python 3.11.5 (main, Aug 31 2023, 21:56:30) [GCC 13.2.1 20230826] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
[1]+  Stopped                 python
^C^C^C^C^C^C^C
riscv32 ~ # ^C
riscv32 ~ # 
riscv32 ~ # jobs
[1]+  Stopped                 python
riscv32 ~ # fg
python


>>> 

--- make, when building something, seems to always start only one job in 
parallel


I applied an ugly trick: I replaced /bin/bash with a static x86-64 binary, 
bypassing
qemu and everything riscv32 for bash only. With that I was able to have the 
chroot
rebuild itself fully natively with our package manager. All obvious problems 
were gone.

So that's roughly where I stand. I went here first, but will obviously also 
go to the qemu people...

Thanks a lot & best,
Andreas



[1] 
This is a standard setup that works great for many architectures, including 
riscv64.
Gentoo builds the installation stages for alpha, mips, riscv64, m68k, 
aarch64_be,
loong64 like this.


> 
> > run-builtins
> > warning: some of these tests may fail if process substitution has not
> > warning: been compiled into the shell or if the OS does not provide
> > warning: /dev/fd.
> > 88,89c88,89
> > < /var/tmp/portage/app-shells/bash-5.2_p15-r6/work/bash-5.2/bash
> > < /var/tmp/portage/app-shells/bash-5.2_p15-r6/work/bash-5.2/bash
> > ---
> >> specialname
> >> -specialname
> 
> This means that for some reason `exec -a' is not working to replace
> argv[0] with the supplied argument. execve(2) might be undoing that.
> 
> > run-execscript
> > warning: the text of a system error message may vary between systems and
> > warning: produce diff output.
> > warning: UNIX versions number signals differently.
> > warning: If output differing only in line numbers is produced, please
> > warning: do not consider this a test failure.
> > warning: if the text of the error messages concerning `notthere' or
> > warning: `/tmp/bash-notthere' not being found or `/' being a directory
> > warning: produce diff output, please do not consider this a test failure
> > warning: if diff output differing only in the location of the bash
> > warning: binary appears, please do not consider this a test failure
> > 24d23
> > < trap -- 'echo USR1' SIGUSR1
> > 25a25
> >> trap -- 'echo USR1' SIGUSR1
> > 30d29
> > < trap -- 'echo USR1' SIGUSR1
> > 31a31
> >> trap -- 'echo USR1' SIGUSR1
> > 47c47
> > < this is /var/tmp/portage/app-shells/bash-5.2_p15-r6/work/bash-5.2/bash
> > ---
> >> this is ohio-state
> 
> Same.
> 
> > < glob2.sub: warning: you do not have the zh_HK.big5hkscs locale installed;
> > < glob2.sub: warning: that will cause some of these tests to fail.
> > 9d6
> > < ./glob2.sub: line 44: warning: setlocale: LC_ALL: cannot change locale 
> > (zh_HK.big5hkscs): No such file or directory
> 
> The warning is valid and causes test failures.
> 
> 
> 
> > run-heredoc
> > warning: UNIX versions number signals and schedule processes differently.
> > warning: If output differing only in line numbers is produced, please
> > warning: do not consider this a test failure.
> > 129c129
> > < /bin/grep: *.c: No such file or directory
> > ---
> >> grep: *.c: No such file or directory
> 
> Spurious, but it indicates that something is modifying argv[0] in execve.
> 
> 
> > run-posixexp
> > 309d308
> > < ./posixexp.tests: line 98: syntax error: unexpected end of file
> 
> Did you remake y.tab.c? And if so, what version of bison did you use?
> 
> 
> > run-read
> > warning: please do not consider output differing only in the amount of
> > warning: white space to be an error.
> > 47c47
> > < a
> > ---
> >> abcde
> > 71c71
> > < 0
> > ---
> >> 1
> > 74c74
> > < 1
> > ---
> >> timeout 2: ok
> > 80c80
> > < a
> > ---
> >> abcde
> 
> These indicate that read with a timeout through a pipe or from /dev/tty is
> failing (or very slow) for some reason. It's strange, since the data is
> already written to the pipe and waiting to be read when the `read' builtin
> is called. The /dev/tty tests can be fooled by typeahead while the tests
> are running, but that doesn't usually happen.
> 
> 


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

signature.asc
Description: This is a digitally signed message part.