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
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
