Re: [Qemu-devel] [RFC qom-cpu 00/41] QOM CPUState, part 13: Emptying CPU_COMMON

[Michael Walle]

Am Montag, 9. September 2013, 18:47:21 schrieb Peter Maydell:
> On 9 September 2013 17:39, Michael Walle <address@hidden> wrote:
> > Am 2013-09-04 11:04, schrieb Andreas Färber:
> >> On part 11, rth said for alpha that using CPUAlphaState in
> >> DisasContext was bad
> >> and that the relevant fields should be copied into DisasContext
> >> instead; a few
> >> targets still have an env field though and use it for register access
> >> and cpu_abort(), so I have just changed the type for now and call upon
> >> maintainers
> >> to review whether they want to do different changes.
> > 
> > Is there a preferred way to abort translation, if for example, the
> > translator finds an unknown opcode? I guess there should be some kind of
> > exception. But speaking of lm32, the real CPU, does not handle such a
> > situation, instead the behavior is just undefined.
> 
> If for the real CPU it's genuinely undefined we can do
> what we like, but killing QEMU is probably a bit harsh.
> If the CPU supports some kind of plausible exception
> then we can use it. Otherwise translate as no-op, maybe.
> In either case doing a qemu_log_mask(LOG_GUEST_ERROR, ...)
> would be a good plan.

Ok. i already have a patch which does this.

> For lm32 you might consider raising EXCP_BREAKPOINT;
> then if you have a gdb connected to the debug stub
> the developer will get dropped into the debugger for
> the offending insn and can look at it.

Are you sure, this will drop to the debugger? I guess the target cpu jumps to 
the exception vector.

I must admit, i'm not very familiar with the gdbstub and exception handling.

-- 
michael