randomly wrong opcode

[Turro75]

Hi Uri,

as wrote Yesterday in discord channel sometimes it happens I get:

Warning: Instruction at 10008682 is not implemented yet!
Opcode: 0xf7f0 (0xa000)

I wrote an additional console.log to inspect the actual flash content and it matches what the warning reports: At PC=0x10008682 0xf7f0a00 => opcode1=f7f0 Opcode2=0xa000

in gdb disas /r give me something different: 0x10008682 <+222>: 00 f0 df fb bl 0x10008e44 <mbed_mem_trace_unlock()>

I attached source and compiled hex/elf files in case You want to use the same values I'm using Arduino mbed core with symbol debug. Build.zip

blink2.ino.zip

The fault happens with this workflow:

gdb-multiarch -ex "file Build/blink2.ino.elf" -ex "target remote localhost:3333"
b *0x10008672
c (breakpoint hit)
n
n -> this shows the unimplemented instruction warning as said above

[urish]

Thanks for the detailed report!

This reproduces here, however, I am seeing that GDB is writing this value to the same location just before the warning appears:

write f0 to 10008682
write f7 to 10008683
write 0 to 10008684
write a0 to 10008685
Warning: Instruction at 10008682 is not implemented yet!
Opcode: 0xf7f0 (0xa000)

also, looking at the GDB protocol dump:

Sending packet: $m10008682,4#66...Ack
Packet received: 00f0dffb
Sending packet: $M10008682,4:f0f700a0#a4...Ack
Packet received: OK
Sending packet: $vCont;c#a8...Ack

So perhaps GDB is trying to set a breakpoint but uses non thumb encoding? I recall we had something similar in one of the previous streams

[Turro75]

I see now the gdbserver code that M overwrites the flash content so an "observer effect" due to a gdb-multiarch bug?

[urish]

Ok, I think I figured this out:

Seems like 0xf7f0 0xa000 encodes UDF.W 0 in the T2 encoding, but we didn't implement this encoding. So instead of breaking into GDB it just skips the first instruction and then executes 0xa000, which decodes to add r0, pc, #0 which probably creates a mess.

[urish]

I see now the gdbserver code that M overwrites the flash content so an "observer effect" due to a gdb-multiarch bug?

observer effect - yes, but it's our bug (see my previous comment)