From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:58191)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1R0wxX-00082v-9a
	for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:16 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1R0wxV-0002qt-Ho
	for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:07 -0400
Received: from mail-vw0-f45.google.com ([209.85.212.45]:47535)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1R0wxV-0002qk-FP
	for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:05 -0400
Received: by vws17 with SMTP id 17so5140340vws.4
	for <qemu-devel@nongnu.org>; Tue, 06 Sep 2011 07:49:04 -0700 (PDT)
Sender: Richard Henderson <rth7680@gmail.com>
Message-ID: <4E6632D7.6070008@twiddle.net>
Date: Tue, 06 Sep 2011 20:18:55 +0530
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
References: <alpine.LNX.2.00.1109031417430.1511@linmac>	<4E62E214.4080400@twiddle.net>
	<alpine.LNX.2.00.1109040632250.1599@linmac>
In-Reply-To: <alpine.LNX.2.00.1109040632250.1599@linmac>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] TCG sar UB (fwd)
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: malc <av1474@comtv.ru>
Cc: qemu-devel@nongnu.org

On 09/04/2011 08:03 AM, malc wrote:
> On Sun, 4 Sep 2011, Richard Henderson wrote:
> 
>> On 09/03/2011 03:47 PM, malc wrote:
>>> Doesn't make much sense to me, guest clearly asked for 0 and not -1,
>>> besides -1 violates TCG's sar constraints and PPC obliges by emiting
>>> illegal instruction in this case.
>>
>> The shift that the guest asked for was completely folded away.
>>
>> The -1 comes from gen_shift_rm_T1 in the computation of the new
>> flags value.  This could instead be moved inside the test for != 0,
>> which is the only place that value is actually used anyway.
>>
>> Try this.  Lightly tested.
> 
> Now i either get hosts illegal instruction or (with logging enabled) a
> guest kenrnel panic.

Hum.  Well, it's possible I made some silly mistake in the patch.
You now know where to look for the problem.

That said, it seems easier for you in the PPC port to mask the 
immediate operand so that you don't produce an illegal instruction.
It doesn't really matter what value that insn produces, as the
result won't be used.


r~