qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC qom-cpu 00/41] QOM CPUState, part 13: Emptying CPU_COMMON
Date: Mon, 9 Sep 2013 17:47:21 +0100

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.

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.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]