On Sun, Sep 17, 2023 at 8:38 AM Andreas K. Huettel <dilfri...@gentoo.org> wrote: > > Am Donnerstag, 14. September 2023, 03:22:49 CEST schrieb Andreas K. Huettel: > > > > https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00119.html > > > > ^ Here I'm trying to find out more. > > > > > > > > Bash tests apparently indicate that argv[0] is overwritten, and that > > > > reading through a pipe or from /dev/tty fails or loses data. > > > > > > > > Apart from the bash testsuite failing, symptoms are as follows: > > > > > > > > * Something seems wrong in the signal handling (?): > > > > > > If it is wrong for signal handling and for 32-bit, I guess it may be > > > fixed by this patch > > > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg981238.html > > > > > > And this patch has been merged into master branch yesterday. > > > > > > May be you can have a try based on the master branch. > > > > I added the patch to 8.0.3 (easier for the moment), and this did > > unfortunately *not* lead to any improvements. > > Also with the patch on top of 8.1.0 no improvement or change. > > > However, in the meantime on the GNU Make tracker Alejandro Colomar > > pointed me to another detail based on my oddities [1]: > > > > > I think [make] it's failing here: > > > > > > <https://git.savannah.gnu.org/cgit/make.git/tree/src/job.c#n757> > > > > > > But it's failing with ENOENT, which is not one of the documented > > > errors for wait(2): > > > > So maybe another point to look at would be the origin of the return > > values of wait, and whether that's wired correctly for rv32... > > > > [1] https://savannah.gnu.org/bugs/?64664 > > In the meantime I tried to nail down a reproducible hang in bash on this > frankensystem with qemu's gdb interface. This also pointed towards > child handling and wait [2].
RV32 only has the time64 wait syscall, so it's possible there is a bug there which then wouldn't appear on other arches. You can see the glibc implementation of wait here [1] to give you an idea of how complex it ends up being. It would be great to get a strace of the failure to narrow down what it is. From there it should be not too hard to find and fix. 1: https://github.com/bminor/glibc/blob/bb5bbc20702981c287aa3e44640e7d2f2b9a28cf/sysdeps/unix/sysv/linux/wait4.c#L26 Alistair > > [2] https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00128.html > > Some time ago we already debugged that corner, and Alistair Francis > came up with a fix that improved the riscv32 situation back then [3]. > Maybe that fix was somehow incomplete? Just speculating... > > [3] https://bugs.launchpad.net/qemu/+bug/1906193 > > > -- > Andreas K. Hüttel > dilfri...@gentoo.org > Gentoo Linux developer > (council, toolchain, base-system, perl, libreoffice)
