Re: Invalid ARM instruction for clang-compiled Android code

[Richard Henderson]

On 11/15/19 12:03 PM, Peter Maydell wrote:
> On Fri, 15 Nov 2019 at 05:03, Michael Goffioul
> <address@hidden> wrote:
>> When running QEMU user mode on some code compiled by clang (dynamic linker 
>> from AOSP-10), the emulator chokes on this instruction:
>>
>>    9aa92:       e8c0 2277       strexd  r7, r2, r2, [r0]
> 
> I think that ought to be a valid insn...
> 
>> From debugging, I determined that op_strex() calls unallocated_encoding(), 
>> which I think leads to the SIGILL signal generated.
>>
>> I run the emulator without specifying the ARM cpu type, I think it then 
>> defaults to "any", which should support all instructions, if I'm not 
>> mistaken.
>>
>> Is this instruction really invalid? Or am I doing something wrong?
> 
> Which version of QEMU are you using? (Looking at the code I
> suspect we still have this bug in master, but it's always
> useful to specify what version you're using in a bug report.)
> 
> Richard, I think we're tripping over the check you added
> in commit af2882289951e. Specifically:
> 
> +    /* We UNDEF for these UNPREDICTABLE cases.  */
> +    if (a->rd == 15 || a->rn == 15 || a->rt == 15
> +        || a->rd == a->rn || a->rd == a->rt
> +        || (s->thumb && (a->rd == 13 || a->rt == 13))
> +        || (mop == MO_64
> +            && (a->rt2 == 15
> +                || a->rd == a->rt2 || a->rt == a->rt2
> +                || (s->thumb && a->rt2 == 13)))) {
> +        unallocated_encoding(s);
> +        return true;
> +    }
> 
> in the mop == MO_64 subclause we check for
>  a->rt == a->rt2
> so we will UNDEF for rt == rt2, as in this example. But the
> pseudocode in the spec doesn't say that rt == rt2 is
> an UNPREDICTABLE case. (It is an UNDPREDICTABLE
> case for LDREXD, but STREXD lets you write the same
> register twice if you want to.) Or am I misreading this?

You're right.  Too much cut-and-paste between strexd and ldrexd.


r~