On 21 December 2014 at 16:21, Michel Boaventura <michel.boavent...@gmail.com> wrote: > Everything works fine. I can run bash, busybox, ash, but when I try to > run a ls or just type an invalid command, I got the attached sequence of > messages, which end like so: > > 11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) > qemu: fatal: Illegal instruction: 0000 @ f6fffa30 > D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) > D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) > D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) > D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) > D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) > D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) > D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) > D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) > PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 > Aborted > > How can I debug it further to try to figure out if this is a qemu issue > or not? Thanks
This is almost certainly a QEMU bug -- m68k/Coldfire is unmaintained upstream right now. I would start debugging this with QEMU's -d and -D options: you can use "-d in_asm,exec,cpu -D logfile.out" to write a lot of logging information about the guest code QEMU executes. (This can be a huge volume, so best to use the shortest possible reproducing command. Take out 'exec' if it's really too slow.) Then you can see what the code the guest executed was and figure out what happened. Alternatively you can try using qemu's debug stub: pass QEMU "-g 1234" and then connect a coldfire gdb using gdb's "target remote :1234" command. Either way, what you want to find out is what exactly happened in the instructions between the waitpid and the crash. My current guess is that either we've messed up the waitpid (seems unlikely, it's not very complicated), or we're not getting signal handling right (much more complicated and likely to have bugs): your crash happens at about the point where the shell is due to receive a SIGCHLD for the child process it spawned. If you send the shell a signal in some other way (eg type ctrl-C at it, or send it a SIGINT from outside QEMU) does it die in a similar way? PS: an easier way to enable strace for linux-user in a binfmt-misc chroot is to use the QEMU_STRACE environment variable. (All the linux-user command line options have environment variable versions; check --help.) You can also just use a command like 'chroot my-chroot /usr/bin/qemu-m68k-static -strace /bin/sh -c /bin/ls' for a one-off command run. -- PMM
