Investigate MSR instruction

[Turro75]

based on gdbdiff I found a wrong sp value after this instruction:
0x100023b0 <svcRtxKernelStart+92>: 83 f3 14 88 msr CONTROL, r3

Mismatch after 73528 compared instructions

Register StartValue Emulator Silicone
r0 0x20004d84 0x20004d84 0x20004d84
r1 0x00000000 0x00000000 0x00000000
r2 0x20004e0c 0x20004e0c 0x20004e0c
r3 0x00000002 0x00000002 0x00000002
r4 0x00000000 0x00000000 0x00000000
r5 0x20002a3c 0x20002a3c 0x20002a3c
r6 0x18000000 0x18000000 0x18000000
r7 0x10002355 0x10002355 0x10002355
r8 0xffffffff 0xffffffff 0xffffffff
r9 0xffffffff 0xffffffff 0xffffffff
r10 0x20030000 0x20030000 0x20030000
r11 0x00000000 0x00000000 0x00000000
r12 0x200001e9 0x200001e9 0x200001e9
sp* 0x2003ffa0 0xfffffffc 0x2003ffa0
lr 0x100038ff 0x100038ff 0x100038ff
pc 0x100023b0 0x100023b4 0x100023b4
xPSR 0x2100000b 0x2100000b 0x2100000b

another:
0x10001d82 <SVC_Handler+82>: 80 f3 09 88 msr PSP, r0
Mismatch after 73552 compared instructions

Register StartValue Emulator Silicone
r0 0x20003958 0x20003958 0x20003958
r1 0x00000000 0x00000000 0x00000000
r2 0x20004d84 0x20004d84 0x20004d84
r3 0x20002a50 0x20002a50 0x20002a50
r4 0x00000000 0x00000000 0x00000000
r5 0x00000000 0x00000000 0x00000000
r6 0x00000000 0x00000000 0x00000000
r7 0x00000000 0x00000000 0x00000000
r8 0x00000000 0x00000000 0x00000000
r9 0x00000000 0x00000000 0x00000000
r10 0x00000000 0x00000000 0x00000000
r11 0x00000000 0x00000000 0x00000000
r12 0x200001e9 0x200001e9 0x200001e9
sp* 0x2003ffb8 0x20003958 0x2003ffb8
lr 0xfffffff9 0xfffffff9 0xfffffff9
pc 0x10001d82 0x10001d86 0x10001d86
xPSR 0x0100000b 0x0100000b 0x0100000b

to recreate use test-printf.ino.elf/hex files You shared then "break _start" and run gdbdiff

[urish]

I think in case of updating SP/CONTROL, it may take more than one instruction for the update to be reflected.

I could be wrong - but what's the instruction that comes right after msr? Is it one of the synchronization instructions (ISB/DSB/DMB)?

[Turro75]

0x1000239e <svcRtxKernelStart+74>: 01 f0 11 fa bl 0x100037c4
0x100023a2 <svcRtxKernelStart+78>: 01 f0 a5 fa bl 0x100038f0
0x100023a6 <svcRtxKernelStart+82>: 13 4b ldr r3, [pc, #76] ; (0x100023f4 <svcRtxKernelStart+160>)
0x100023a8 <svcRtxKernelStart+84>: 1b 68 ldr r3, [r3, #0]
0x100023aa <svcRtxKernelStart+86>: db 07 lsls r3, r3, #31
0x100023ac <svcRtxKernelStart+88>: 1a d5 bpl.n 0x100023e4 <svcRtxKernelStart+144>
0x100023ae <svcRtxKernelStart+90>: 02 23 movs r3, #2
0x100023b0 <svcRtxKernelStart+92>: 83 f3 14 88 msr CONTROL, r3
0x100023b4 <svcRtxKernelStart+96>: 0d 4b ldr r3, [pc, #52] ; (0x100023ec <svcRtxKernelStart+152>)
0x100023b6 <svcRtxKernelStart+98>: 02 22 movs r2, #2
0x100023b8 <svcRtxKernelStart+100>: 1a 72 strb r2, [r3, #8]
0x100023ba <svcRtxKernelStart+102>: 20 00 movs r0, r4
0x100023bc <svcRtxKernelStart+104>: 70 bd pop {r4, r5, r6, pc}
0x100023be <svcRtxKernelStart+106>: 07 20 movs r0, #7
0x100023c0 <svcRtxKernelStart+108>: 40 42 negs r0, r0
0x100023c2 <svcRtxKernelStart+110>: 01 f0 77 ff bl 0x100042b4
0x100023c6 <svcRtxKernelStart+114>: 01 24 movs r4, #1
0x100023c8 <svcRtxKernelStart+116>: 64 42 negs r4, r4

0x10001d78 <SVC_Handler+72>: f0 c8 ldmia r0!, {r4, r5, r6, r7}
0x10001d7a <SVC_Handler+74>: a0 46 mov r8, r4
0x10001d7c <SVC_Handler+76>: a9 46 mov r9, r5
0x10001d7e <SVC_Handler+78>: b2 46 mov r10, r6
0x10001d80 <SVC_Handler+80>: bb 46 mov r11, r7
0x10001d82 <SVC_Handler+82>: 80 f3 09 88 msr PSP, r0
0x10001d86 <SVC_Handler+86>: 20 38 subs r0, #32
0x10001d88 <SVC_Handler+88>: f0 c8 ldmia r0!, {r4, r5, r6, r7}
0x10001d8a <SVC_Handler+90>: 02 20 movs r0, #2
0x10001d8c <SVC_Handler+92>: c0 43 mvns r0, r0
0x10001d8e <SVC_Handler+94>: 00 47 bx r0
0x10001d90 <SVC_Handler+96>: ef f3 08 80 mrs r0, MSP
0x10001d94 <SVC_Handler+100>: d1 e7 b.n 0x10001d3a <SVC_Handler+10>
0x10001d96 <SVC_Handler+102>: 70 47 bx lr

[urish]

Then the next question is: does SP eventually update to the new value?

i.e. after this instruction:

0x10001d82 <SVC_Handler+82>: 80 f3 09 88 msr PSP, r0

in the silicone sp is still 0x2003ffb8, but if we step a few more instructions, does it update to 0x20003958?

I think it will also help if we print the values of MSP/PSP (GDB registers 17/18), to see if they are updated after this instruction

[Turro75]

Not able to reproduce it anymore, may be the various instruction fixes solve even this issue

[urish]

Thank you for testing this!