Qemu crashes with chrooted m68k
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine.
I've been able to use binfmt_msc and used the above code to use qemu with strace:
#include <unistd.h>
#include <string.h>
int main(int argc, char **argv, char **envp) {
char *newargv[argc + 4];
newargv[0] = argv[0];
newargv[1] = "-cpu";
newargv[2] = "cfv4e";
newargv[3] = "-strace";
return execve(
}
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(
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
On 21 December 2014 at 16:21, Michel Boaventura -1,0xf6fffa00, 0x3) = -1 errno=10 (No child processes)
<email address hidden> 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(
> 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 qemu-m68k- static -strace /bin/sh -c /bin/ls'
'chroot my-chroot /usr/bin/
for a one-off command run.
-- PMM