Disassembler disagrees with translator over instruction decoding

Disassembler disagrees with translator over instruction decoding

[Станислав Юдин]

[-- Attachment #1.1: Type: text/plain, Size: 565 bytes --]

Hello,

I've just got this message, when I dubugging my code:

*Disassembler disagrees with translator over instruction decoding
Please report this to qemu-devel@nongnu.org*

Binary code is in the attachment.

It launches by this command:

"c:\Program Files\qemu\qemu-system-arm.exe" -M vexpress-a9 -serial stdio 
-m 512M -kernel speciarmlist.bin -d in_asm

qemu-system-arm.exe -version
QEMU emulator version 8.0.94 (v8.1.0-rc4-12032-g74a4cbee04)
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers


--
C уважением, Станислав

[-- Attachment #1.2.1: Type: text/html, Size: 996 bytes --]

[-- Attachment #1.2.2: gGlkdlZVVL1kGZIl.png --]
[-- Type: image/png, Size: 56976 bytes --]

[-- Attachment #2: speciarmlist.7z --]
[-- Type: application/octet-stream, Size: 12437 bytes --]

Re: Disassembler disagrees with translator over instruction decoding

[Alex Bennée]

Станислав Юдин <CityAceE@reext.ru> writes:

> Hello,
>
> I've just got this message, when I dubugging my code:
>
> Disassembler disagrees with translator over instruction decoding
> Please report this to qemu-devel@nongnu.org
>
> *
>
> Binary code is in the attachment.

The binary seems to reconfigure itself as it executes as I can't find
the instructions in the objdump. However via gdbstub we get to:

  (gdb) x/4i $pc
  => 0x60011ab8:  pop     {r0, r1, r2, r3, r4, r5, r6, pc}
     0x60011aba:  push    {lr}
     0x60011abc:  mov.w   r11, #4
     0x60011ac0:  ldrb.w  r7, [r0, r10]
  (gdb) x/10i 0x60010168
     0x60010168:  ldrb    r6, [r0, r1]
     0x6001016a:  addw    r7, pc, #6
     0x6001016e:  ldr.w   pc, [r7]
     0x60010172:  lsls    r2, r6, #21
     0x60010174:  str     r1, [r0, #0]
     0x60010176:  lsls    r2, r7, #21
     0x60010178:  str     r1, [r0, #0]
     0x6001017a:  lsls    r6, r3, #22
     0x6001017c:  str     r1, [r0, #0]
     0x6001017e:  lsls    r6, r5, #22
  (gdb) hbreak *0x6001016e
  Hardware assisted breakpoint 2 at 0x6001016e
  (gdb) c
  Continuing.

  Breakpoint 2, 0x6001016e in ?? ()
  (gdb) i
  0x60010572 in ?? ()
  => 0x60010572:  streq   pc, [r4, #-421] @ 0xfffffe5b
     0x60010576:  ldmiblt r7, {r0, r12, sp, lr, pc}^
     0x6001057a:  tsteq   r1, r1, lsl #2  @ <UNPREDICTABLE>
  (gdb) x/5i $pc
  => 0x60010572:  streq   pc, [r4, #-421] @ 0xfffffe5b
     0x60010576:  ldmiblt r7, {r0, r12, sp, lr, pc}^
     0x6001057a:  tsteq   r1, r1, lsl #2  @ <UNPREDICTABLE>
     0x6001057e:  smlabteq        r0, r0, r2, pc  @ <UNPREDICTABLE>
     0x60010582:  blt     0x61da66a2
  (gdb) x/10w $pc
  0x60010572:     0x0504f1a5      0xb9d7f001      0x0101f101      0x0100f2c0
  0x60010582:     0xba765846      0x0300f2c0      0x0436bfe1      0x31024333
  0x60010592:     0x0100f2c0      0x050af1a5
  (gdb) 

Which seems to agree with the disassembler from the console:

  (qemu) x/5i 0x60010572
  0x60010572:  0504f1a5  streq    pc, [r4, #-0x1a5]
  0x60010576:  b9d7f001  ldmiblt  r7, {r0, ip, sp, lr, pc} ^
  0x6001057a:  0101f101  mrseq    pc, apsr
  0x6001057e:  0100f2c0  smlabteq r0, r0, r2, pc
  0x60010582:  ba765846  blt      #0x61da66a2

>
> It launches by this command:
>
> "c:\Program Files\qemu\qemu-system-arm.exe" -M vexpress-a9 -serial stdio -m 512M -kernel speciarmlist.bin -d
> in_asm
>
>
> qemu-system-arm.exe -version
> QEMU emulator version 8.0.94 (v8.1.0-rc4-12032-g74a4cbee04)
> Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers


-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: Disassembler disagrees with translator over instruction decoding

[Peter Maydell]

On Mon, 11 Sept 2023 at 12:28, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Станислав Юдин <CityAceE@reext.ru> writes:
>
> > Hello,
> >
> > I've just got this message, when I dubugging my code:
> >
> > Disassembler disagrees with translator over instruction decoding
> > Please report this to qemu-devel@nongnu.org
> >
> > *
> >
> > Binary code is in the attachment.
>
> The binary seems to reconfigure itself as it executes as I can't find
> the instructions in the objdump. However via gdbstub we get to:
>
>   (gdb) x/4i $pc
>   => 0x60011ab8:  pop     {r0, r1, r2, r3, r4, r5, r6, pc}
>      0x60011aba:  push    {lr}
>      0x60011abc:  mov.w   r11, #4
>      0x60011ac0:  ldrb.w  r7, [r0, r10]
>   (gdb) x/10i 0x60010168
>      0x60010168:  ldrb    r6, [r0, r1]
>      0x6001016a:  addw    r7, pc, #6
>      0x6001016e:  ldr.w   pc, [r7]
>      0x60010172:  lsls    r2, r6, #21
>      0x60010174:  str     r1, [r0, #0]
>      0x60010176:  lsls    r2, r7, #21
>      0x60010178:  str     r1, [r0, #0]
>      0x6001017a:  lsls    r6, r3, #22
>      0x6001017c:  str     r1, [r0, #0]
>      0x6001017e:  lsls    r6, r5, #22
>   (gdb) hbreak *0x6001016e
>   Hardware assisted breakpoint 2 at 0x6001016e
>   (gdb) c
>   Continuing.
>
>   Breakpoint 2, 0x6001016e in ?? ()
>   (gdb) i
>   0x60010572 in ?? ()
>   => 0x60010572:  streq   pc, [r4, #-421] @ 0xfffffe5b
>      0x60010576:  ldmiblt r7, {r0, r12, sp, lr, pc}^
>      0x6001057a:  tsteq   r1, r1, lsl #2  @ <UNPREDICTABLE>
>   (gdb) x/5i $pc
>   => 0x60010572:  streq   pc, [r4, #-421] @ 0xfffffe5b
>      0x60010576:  ldmiblt r7, {r0, r12, sp, lr, pc}^
>      0x6001057a:  tsteq   r1, r1, lsl #2  @ <UNPREDICTABLE>
>      0x6001057e:  smlabteq        r0, r0, r2, pc  @ <UNPREDICTABLE>
>      0x60010582:  blt     0x61da66a2
>   (gdb) x/10w $pc
>   0x60010572:     0x0504f1a5      0xb9d7f001      0x0101f101      0x0100f2c0
>   0x60010582:     0xba765846      0x0300f2c0      0x0436bfe1      0x31024333
>   0x60010592:     0x0100f2c0      0x050af1a5
>   (gdb)

Notice that the PC here is not 4-aligned, but the
disassembly is being done in Arm mode. (Presumably the
guest code has messed up trying to jump to Thumb code.)

In the trace in the screenshot, you can also see that the
warning happens after an attempted ldr.w   pc, [r7],
and the next thing translated is at address 0xc, which
is an exception entry point. So likely the complaint is
about the bogus instruction at wherever the incorrect
return address takes us, which provoked an exception.

(Note to the original reporter: you'll find it easier to
debug from -d logging if you add 'exec,cpu,int' to your -d list:
this will then log (a) actual execution with guest register
contents, not just translation-time instruction traces
(b) information about when an exception is taken.)

> Which seems to agree with the disassembler from the console:
>
>   (qemu) x/5i 0x60010572
>   0x60010572:  0504f1a5  streq    pc, [r4, #-0x1a5]
>   0x60010576:  b9d7f001  ldmiblt  r7, {r0, ip, sp, lr, pc} ^
>   0x6001057a:  0101f101  mrseq    pc, apsr
>   0x6001057e:  0100f2c0  smlabteq r0, r0, r2, pc
>   0x60010582:  ba765846  blt      #0x61da66a2

I think we should delete that warning message, personally.
There are a few "expected" corner cases where it can fire,
I think, though I can't remember the details.[*] It wouldn't
surprise me too much if "try to dissassemble in Arm mode
starting at an unaligned address" was one of those cases.
But more generally it assumes that the disassemblers are
reliable sources of information on the length of instructions,
and I don't think that's true any more -- they tend to lag
behind on newer instruction set features and we don't try
to keep them up to date.

[*] One example from 2017, caused by the translator stopping
reading insn bytes in an x86 variable length insn as soon as
it identifies it as not being valid:
https://lore.kernel.org/qemu-devel/CAFEAcA9HLbnZnfBisNLPnKuf364kPtq8=0soFmovYRzRWrOtkA@mail.gmail.com/

thanks
-- PMM