qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH] translate.c: Fix usermode big-endian AArch32 LDRE


From: Peter Maydell
Subject: Re: [Qemu-arm] [PATCH] translate.c: Fix usermode big-endian AArch32 LDREXD and STREXD
Date: Sat, 21 Oct 2017 11:17:45 +0100

On 20 October 2017 at 19:15, Richard Henderson <address@hidden> wrote:
> On 10/20/2017 10:56 AM, Peter Maydell wrote:
>> +        if (s->be_data) {
>> +            tcg_gen_extr_i64_i32(tmp2, tmp, t64);
>> +        } else {
>> +            tcg_gen_extr_i64_i32(tmp, tmp2, t64);
>> +        }
>
> The test against be_data must be of the form s->be_data == MO_BE/LE.
>
> The actual bits have MO_BSWAP non-zero, and then set MO_BE/LE to either 0 or
> MO_BSWAP depending on the host endianness.

Oops, yes.

>> -        gen_aa32_frob64(s, o64);
>> +        if (s->be_data) {
>> +            tcg_gen_rotri_i64(o64, o64, 32);
>> +        }
>>          tcg_gen_setcond_i64(TCG_COND_NE, o64, o64, cpu_exclusive_val);
>
> We're not splitting o64 to parts.  Are you sure it shouldn't stay as frob?

This is confusing, but I don't think frob is right. We want to
be matching either (a) the transformation we just did to produce
the 64 bit data we're storing, or (b) the transformation we
do on the ldrexd, don't we? Neither of those is frob.

I think I need to think through a bit more carefully about
what's actually going on here, since we seem to have the
value in two places (actual memory, and the cpu_exclusive_val
TCGv.)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]