Am Montag, 9. September 2013, 18:47:21 schrieb Peter Maydell: > On 9 September 2013 17:39, Michael Walle <mich...@walle.cc> 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
