* Re: Invalid ARM instruction for clang-compiled Android code
[not found] <CAB-99Lv3LySps4MOoKEj7Sp0CBouv-KgZp2osbiokSq_Gdfj5Q@mail.gmail.com>
@ 2019-11-15 11:03 ` Peter Maydell
2019-11-15 11:58 ` Michael Goffioul
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Peter Maydell @ 2019-11-15 11:03 UTC (permalink / raw)
To: Michael Goffioul; +Cc: Richard Henderson, QEMU Developers, qemu-discuss
On Fri, 15 Nov 2019 at 05:03, Michael Goffioul
<michael.goffioul@gmail.com> 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?
thanks
-- PMM
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Invalid ARM instruction for clang-compiled Android code
2019-11-15 11:03 ` Invalid ARM instruction for clang-compiled Android code Peter Maydell
@ 2019-11-15 11:58 ` Michael Goffioul
2019-11-15 14:01 ` Michael Goffioul
2019-11-17 8:45 ` Richard Henderson
2 siblings, 0 replies; 4+ messages in thread
From: Michael Goffioul @ 2019-11-15 11:58 UTC (permalink / raw)
To: Peter Maydell; +Cc: Richard Henderson, QEMU Developers, qemu-discuss
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Fri, Nov 15, 2019 at 6:03 AM Peter Maydell <peter.maydell@linaro.org>
wrote:
> On Fri, 15 Nov 2019 at 05:03, Michael Goffioul
> <michael.goffioul@gmail.com> 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.)
>
Yes sorry, I forgot to mention it. I'm using master branch
at 187f35512106501fe9a11057f4d8705431e0026d
[-- Attachment #2: Type: text/html, Size: 1558 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Invalid ARM instruction for clang-compiled Android code
2019-11-15 11:03 ` Invalid ARM instruction for clang-compiled Android code Peter Maydell
2019-11-15 11:58 ` Michael Goffioul
@ 2019-11-15 14:01 ` Michael Goffioul
2019-11-17 8:45 ` Richard Henderson
2 siblings, 0 replies; 4+ messages in thread
From: Michael Goffioul @ 2019-11-15 14:01 UTC (permalink / raw)
To: Peter Maydell; +Cc: Richard Henderson, QEMU Developers, qemu-discuss
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
On Fri, Nov 15, 2019 at 6:03 AM Peter Maydell <peter.maydell@linaro.org>
wrote:
> 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?
>
BTW, I can confirm that removing the check "a->rt == a->rt2" seems to fix
my problem.
[-- Attachment #2: Type: text/html, Size: 1590 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Invalid ARM instruction for clang-compiled Android code
2019-11-15 11:03 ` Invalid ARM instruction for clang-compiled Android code Peter Maydell
2019-11-15 11:58 ` Michael Goffioul
2019-11-15 14:01 ` Michael Goffioul
@ 2019-11-17 8:45 ` Richard Henderson
2 siblings, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2019-11-17 8:45 UTC (permalink / raw)
To: Peter Maydell, Michael Goffioul; +Cc: QEMU Developers, qemu-discuss
On 11/15/19 12:03 PM, Peter Maydell wrote:
> On Fri, 15 Nov 2019 at 05:03, Michael Goffioul
> <michael.goffioul@gmail.com> 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~
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-11-17 8:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAB-99Lv3LySps4MOoKEj7Sp0CBouv-KgZp2osbiokSq_Gdfj5Q@mail.gmail.com>
2019-11-15 11:03 ` Invalid ARM instruction for clang-compiled Android code Peter Maydell
2019-11-15 11:58 ` Michael Goffioul
2019-11-15 14:01 ` Michael Goffioul
2019-11-17 8:45 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).