From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nll5A-00010D-Dk
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:29:24 -0500
Received: from [199.232.76.173] (port=53706 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nll5A-000103-0y
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:29:24 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <aurelien@aurel32.net>) id 1Nll58-0002Zo-Vh
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:29:24 -0500
Received: from hall.aurel32.net ([88.191.82.174]:59433)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <aurelien@aurel32.net>)
	id 1Nll58-0002Zg-MJ
	for qemu-devel@nongnu.org; Sun, 28 Feb 2010 10:29:22 -0500
Date: Sun, 28 Feb 2010 16:29:20 +0100
From: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [Bug] qemu-system-ppc: "invalid/unsupported
	opcode" during debug session
Message-ID: <20100228152920.GC8952@hall.aurel32.net>
References: <4B3A1B9D.7010004@mail.berlios.de>
	<20100228131830.GJ10291@volta.aurel32.net>
	<20100228152542.GA28486@shareable.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20100228152542.GA28486@shareable.org>
Sender: Aurelien Jarno <aurelien@aurel32.net>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>

On Sun, Feb 28, 2010 at 03:25:42PM +0000, Jamie Lokier wrote:
> Aurelien Jarno wrote:
> > It is not a full fix, as the OS can actually use any instruction that
> > always generate a trap (even a memory access) as an instruction barrier
> > to make sure the following instructions are never executed. This
> > actually affects all targets, but is unlikely to happen.
> 
> I'm sure I've seen code wich intentionally accesses invalid memory,
> followed by non-instruction data such as a message to print.  But I
> can't think where.
> 

As Paul Brook explained, I am actually wrong. We don't generate an
exception in that case, but code that will generated an exception. If an
exception appears before, this code will never been executed.

So the best is to ignore this mail ;-)

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net