Re: [Qemu-devel] Problems with MIPS full system emulation and breakpoints: also for FPU emulation

[Stefan Weil]

A similar patch for EXCP_AdEL seems to fix the problems
with Linux floating point emulation.

Linux uses self modifying code on the stack in the FPU emulation
and terminates this code using "lw    zero,1(zero)"
(which raises EXCP_AdEL).

Sometimes, a system call which follows and is also on the stack
does not raise EXCP_SYSCALL but raises EXCP_AdEL, so the calling
process gets a signal SIGILL.

I tested this by running aptitude on Debian 4.0.

It crashs with 4KEc (no FPU, CVS HEAD).
It works with default CPU (FPU, CVS HEAD).
It works with 4KEc (no FPU, patched CVS HEAD).

Stefan

Jason Wessel schrieb:
>
> It seems there is an issue with the translation block flushing when
> writing to the code regions in the MIPS full system emulation.  Using
> a 2.6 kernel which is basically running in single user mode, I use an
> extremely simple program:
>
> ...
> To illustrate the problem further, I attached a patch that makes this
> problem go away.  Of course this is not the right fix, because it only
> deals with the breakpoint opcode and does not isolate the translated
> block that had the instruction that changed.  In theory you should be
> able to modify any part of the instruction code from another process
> with ptrace.
> Are there any suggestions as to how to fix this the right way?  The
> real hardware of course does not exhibit this issue.
>
> Thanks,
> Jason.
>
>
> ------------------------------------------------------------------------
>
> Index: qemu/target-mips/helper.c
> ===================================================================
> --- qemu.orig/target-mips/helper.c
> +++ qemu/target-mips/helper.c
> @@ -360,6 +360,7 @@ void do_interrupt (CPUState *env)
> goto set_EPC;
> case EXCP_BREAK:
> cause = 9;
> + tb_flush(env);
> goto set_EPC;
> case EXCP_RI:
> cause = 10;