From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37474)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aL7VR-0006PS-3C
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 05:57:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aL7VM-0002CN-0P
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 05:57:53 -0500
Received: from mx1.redhat.com ([209.132.183.28]:38576)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1aL7VL-0002CE-RN
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 05:57:47 -0500
References: <569CBCB1.5040004@redhat.com>
	<CAFEAcA_gpdv=zRLaXMRFvXkog7dRt0umjJz=npTL7Zz58fAKuA@mail.gmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <569CC526.4060607@redhat.com>
Date: Mon, 18 Jan 2016 11:57:42 +0100
MIME-Version: 1.0
In-Reply-To: <CAFEAcA_gpdv=zRLaXMRFvXkog7dRt0umjJz=npTL7Zz58fAKuA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] defining VIXL_DEBUG?
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: qemu-devel <qemu-devel@nongnu.org>



On 18/01/2016 11:51, Peter Maydell wrote:
>>  The actual code in the function is
>> >
>> >     default: VIXL_UNREACHABLE(); return 0;
>> >
>> > so this is obviously a false positive.  Defining VIXL_DEBUG would cause
>> > VIXL_UNREACHABLE() to call abort().  Any opinion about whether/where to
>> > do so?
> Does defining it to call abort() result in unreachable-code warnings
> for the "return 0;" ?

I'm not sure, it would be minor though.

One issue I have found after posting is that I'm not sure whether bad
instructions (aka reserved encodings) are handled properly by libvixl.
See for example this:

    case 'A': {  // IAddSub.
      VIXL_ASSERT(instr->ShiftAddSub() <= 1);
      int64_t imm = instr->ImmAddSub() << (12 * instr->ShiftAddSub());
      AppendToOutput("#0x%" PRIx64 " (%" PRId64 ")", imm, imm);
      return 7;
    }

where the '1x' encodings of bits 22:23 (marked as reserved in the ARMv8
ARM) would cause an abort as far as I can see.

Paolo