On Mon, 11 Sept 2023 at 12:28, Alex Bennée <alex.ben...@linaro.org> wrote:
>
>
> Станислав Юдин <citya...@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=0sofmovyrzrwro...@mail.gmail.com/
thanks
-- PMM
