From: Elta <elta.era@gmail.com>
To: Aurelien Jarno <aurelien@aurel32.net>,
Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/2] target-mips/translate.c: Add judgement for msb and lsb
Date: Tue, 29 Jul 2014 20:41:08 +0800 [thread overview]
Message-ID: <53D79664.9070007@gmail.com> (raw)
In-Reply-To: <20140728225254.GA1268@hall.aurel32.net>
On 07/29/2014 06:52 AM, Aurelien Jarno wrote:
> On Mon, Jul 28, 2014 at 11:34:30PM +0100, Peter Maydell wrote:
>> On 28 July 2014 23:32, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>> On Mon, Jul 28, 2014 at 11:01:02PM +0100, Peter Maydell wrote:
>>>> This may be true, but the TCG README doesn't define negative
>>>> lengths as being "unspecified behaviour" (ie guaranteed to at
>>>> least not crash even if the result isn't specified), and in fact the
>>>> implementation of tcg_gen_deposit will assert on negative lengths.
>>>> We shouldn't implement guest unpredictable cases as "crash QEMU".
>>> Well I tried this code under QEMU, and it clearly doesn't crash. It
>>> seems the assert are not enabled with the default configuration options.
>> Try --enable-debug...
> That's my point, it's only in debug mode, not in the default
> configuration.
Maybe remove the tcg_debug_assert in tcg_gen_deposit_i64 and
tcg_gen_deposit_i64
is a better way. But it may cause other mistake in other architecture,
i'm not
sure.
>
>>> That said I agree it's something to avoid, but I don't think triggering
>>> a RI exception is the thing to do (even if it is correct according the
>>> MIPS ISA manual) when real silicon output a random result instead.
>> Yes, you could emit code to do that instead if you like.
> When I said random, it didn't say in the sense of random generator, but
> in the sense a result that might depend on the input value and the
> silicon implementation. It would be silly to emit code just for that,
> but it would be smart for example to skip the deposit op in that case
> instead of triggering an exception.
>
I think, debug mode shouldn't crash the qemu with an unpredictable
operation,
so i want to fix it. And you say there shouldn't raise RI, i agree with you.
Or when lsb > msb, just leave the code and do nothing. What do you think
about
this way?
next prev parent reply other threads:[~2014-07-29 12:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 15:58 [Qemu-devel] [PATCH 1/2] target-mips/translate.c: Free TCG in OPC_DINSV Dongxue Zhang
2014-07-28 15:58 ` [Qemu-devel] [PATCH 2/2] target-mips/translate.c: Add judgement for msb and lsb Dongxue Zhang
2014-07-28 21:42 ` Aurelien Jarno
2014-07-28 22:01 ` Peter Maydell
2014-07-28 22:32 ` Aurelien Jarno
2014-07-28 22:34 ` Peter Maydell
2014-07-28 22:52 ` Aurelien Jarno
2014-07-29 12:41 ` Elta [this message]
2014-07-29 14:08 ` Aurelien Jarno
2014-07-29 15:32 ` Dongxue Zhang
2014-07-29 12:47 ` Peter Maydell
2014-07-28 21:42 ` [Qemu-devel] [PATCH 1/2] target-mips/translate.c: Free TCG in OPC_DINSV Aurelien Jarno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D79664.9070007@gmail.com \
--to=elta.era@gmail.com \
--cc=aurelien@aurel32.net \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.