From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57390)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VLzMR-0002tY-J6
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:46:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VLzMM-0004Dz-MS
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:46:51 -0400
Received: from ssl.serverraum.org ([88.198.40.39]:36803)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <michael@walle.cc>) id 1VLzMM-0004Dt-GD
	for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:46:46 -0400
From: Michael Walle <michael@walle.cc>
Date: Tue, 17 Sep 2013 19:46:43 +0200
References: <1378285521-3230-1-git-send-email-afaerber@suse.de>
	<c46ffb916a381e3d00ff0baf4778ec70@walle.cc>
	<CAFEAcA-sW6Z6f0ZkO0T9TtSOgH+bqn-u7JfkwHODx9UJ_Pdvzw@mail.gmail.com>
In-Reply-To: <CAFEAcA-sW6Z6f0ZkO0T9TtSOgH+bqn-u7JfkwHODx9UJ_Pdvzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201309171946.43311.michael@walle.cc>
Subject: Re: [Qemu-devel] [RFC qom-cpu 00/41] QOM CPUState,
	part 13: Emptying CPU_COMMON
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com>, Eduardo Habkost <ehabkost@redhat.com>, Riku Voipio <riku.voipio@iki.fi>, QEMU Developers <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>, Blue Swirl <blauwirbel@gmail.com>, Li Guang <lig.fnst@cn.fujitsu.com>, Anthony Liguori <anthony@codemonkey.ws>, Igor Mammedov <imammedo@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Andreas =?utf-8?q?F=C3=A4rber?= <afaerber@suse.de>, =?utf-8?q?Aur=C3=A9lien_Jarno?= <aurelien@aurel32.net>, Richard Henderson <rth@twiddle.net>

Am Montag, 9. September 2013, 18:47:21 schrieb Peter Maydell:
> On 9 September 2013 17:39, Michael Walle <michael@walle.cc> wrote:
> > Am 2013-09-04 11:04, schrieb Andreas F=C3=A4rber:
> >> 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.
> >=20
> > 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.
>=20
> 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=20
the exception vector.

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

=2D-=20
michael