cortex-debug
cortex-debug copied to clipboard
Marus
Disassembly view showing wrong instructions
Describe the bug When a breakpoint is hit in an editor window, and the user opens the disassembly view, the addresses, offsets and instructions there are all mixed up, meaning in the wrong position. Some instructions are usually in the right place, but then there are seemingly random addresses from other locations of the program text intertwined. Some instructions are even in the wrong order (meaning higher addresses appear above lower addresses and vice versa.
After scrolling a page up or down and then back to the current (highlighted) instruction, the disassembly view is reset to showing all the right instructions again as expected.
To Reproduce Steps to reproduce the behavior:
- Start debug session
- Place a breakpoint anywhere
- Run program and wait for breakpoint to be reached
- Open Disassembly view
Expected behavior
All lines of the disassembly are in the correct order.
Screenshots
Before scrolling: (notice even the current, highlighted instruction is incorrect)
After scrolling:
Environment (please complete the following information):
- Cortex-Debug Version v1.12.1
- OS: Windows 10
- GDB Version: 10.1.90.20201028-git
- Compiler Toolchain Version: arm-none-eabi 10-2020-q4-major
Please include launch.json
Note: We are unlikely to look at the issue if you do not supply this
{
"version": "0.2.0",
"configurations": [
{
"type": "cortex-debug",
"request": "launch",
"name": "J-Link Debug Application",
"cwd": "${workspaceFolder}",
"executable": "${workspaceFolder}/Firmware/build/debug/debug.axf",
"serverpath": "${workspaceFolder}/tools/SEGGER/JLink/JLinkGDBServerCL.exe",
"servertype": "jlink",
"armToolchainPath": "${workspaceFolder}/tools/10.2_2020q4/bin",
"gdbPath": "${workspaceFolder}/tools/10.2_2020q4/bin/arm-none-eabi-gdb.exe",
"device": "EFR32BG22CxxxF512",
"interface": "swd",
"serialNumber": "",
"swoConfig": {
"enabled": true,
"swoFrequency": 875000,
"source": "probe",
"cpuFrequency": 38400000,
"decoders": [
{
"port": 0,
"type": "console",
"label": "SWO output",
"encoding": "ascii",
"showOnStartup": true
}
]
},
"rttConfig": {
"enabled": true,
"address": "auto",
"decoders": [
{
"label": "console",
"port": 0,
"type": "console"
}
]
},
"numberOfProcessors": 1,
"showDevDebugOutput": "none",
"runToEntryPoint": "main",
},
Attach text from Debug Console
Please enable debug output in your launch.json ("showDevDebugOutput": "raw"). It this is too large, please attach it as a file
Suppressing output for '883-data-disassemble -s 0x0001f8fc -e 0x0001f98c -- 5'
Debug: Gdb command: -data-disassemble -s 0x0001f98c -e 0x0001fb3c -- 5 432 bytes (tftDriverIF_Start_b)
Debug: Gdb command: -data-disassemble -s 0x0001fb3c -e 0x0001fe50 -- 5 788 bytes (tftDriverIF_StartFade_b)
Suppressing output for '884-data-disassemble -s 0x0001f98c -e 0x0001fb3c -- 5'
Debug: data-disassemble -s 0x0001f8fc -e 0x0001f98c -- 5 => Found 59 instructions. 58 with source code, 1 without
Suppressing output for '885-data-disassemble -s 0x0001fb3c -e 0x0001fe50 -- 5'
Debug: data-disassemble -s 0x0001f98c -e 0x0001fb3c -- 5 => Found 183 instructions. 182 with source code, 1 without
Debug: data-disassemble -s 0x0001fb3c -e 0x0001fe50 -- 5 => Found 324 instructions. 323 with source code, 1 without
Debug-843: Elapsed time for Disassembly Request: 114 ms
Debug-855: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x000084e0","offset":0,"instructionOffset":-200,"instructionCount":400,"resolveSymbols":true},"type":"request","seq":855}
Debug-855: Elapsed time for Disassembly Request: 004 ms
Additional context Add any other context about the problem here.
All lines of the disassembly are in the correct order.
Don't know what you mean by correct order? They are ordered by addresses as returned by GDB. We don't do our own disassembly. But we create the requests (which could be wrong) to gdb to do the work.
You can use gdb from the Debug Console to print the disassembly to see what you get for an address range, and does it match what is in the disassembly window. And, does it make sense?
The initial currenty highlighted line is where your pc is as shown in the stackframe window.
Look at the addresses on the left side (1st screenshot), they should be increasing monotonically. I've marked the ones bold that are 'out of line':
0x82d2
0x82ce
0x84d2
0x84d4
0x84d6
0x82c0
0x84de
0x82ba (shown as pc, reading from the register view, the pc is actually at 0x84e0!)
The pc is actually in the function LDMA_StartTransfer, but you see instructions from other functions (IADC_init) mixed in
We are expecting instructions in sorted order as well. Can you do the following?
- Set "showDevDebugOutput": "none" in launch.json
- Run until you get to your breakpoint
- In the debug console, enter the following and hit enter
disassemble /s 0x811c,0x880a
- Attach what you see from the command above. This is kind what we did with gdb. I want to see what it is returning. I notice that you used a compiler other than GCC (nor sure if it is IAR or ARMCC) which is okay but they can generate some very strange instructions when optimization is turned on.
I used the start and end addresses by looking at what was in the Debug Console at the time. If your program has changed, please adjust the disassemble command accordingly.
I'm using GCC for ARM. Why would you think otherwise?
I tried your suggestion:
Resetting target
Temporary breakpoint 2, main () at src/main.c:61
61 {
Debug-16: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x00000e1c","offset":0,"instructionOffset":-50,"instructionCount":50,"resolveSymbols":true},"type":"request","seq":16}
Note: We detected the following memory regions as valid using gdb "info mem" and "objdump -h"
This information is used to adjust bounds only when normal disassembly fails.
================================================================================
Using following memory regions for disassembly
================================================================================
Size VMA Beg VMA End LMA Beg LMA End Attributes
================================================================================
Unfortunately, No memory information from gdb (or gdb-server). Will try to manage without
------------------------------------------------------------------------------
00001a68 00000000 00001a68 -------- -------- (.text) contents alloc load readonly code
00000008 00001a68 00001a70 -------- -------- (.ARM.exidx) contents alloc load readonly data
00000400 20000000 20000400 -------- -------- (.stack) alloc
00000860 20000400 20000c60 00001a70 000022d0 (.data) contents alloc load data
00000060 20000c60 20000cc0 000022d0 00002330 (.bss) alloc
================================================================================
Debug-16: Dequeuing...
Debug: Gdb command: -data-disassemble -s 0x00000d00 -e 0x00000e88 -- 5 392 bytes (DmaStartTransfer)
Debug: data-disassemble -s 0x00000d00 -e 0x00000e88 -- 5 => Found 150 instructions. 150 with source code, 0 without
Debug-16: Elapsed time for Disassembly Request: 032 ms
Debug-17: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x00000e1c","offset":0,"instructionOffset":0,"instructionCount":50,"resolveSymbols":true},"type":"request","seq":17}
Debug-17: Dequeuing...
Debug: Gdb command: -data-disassemble -s 0x00000e1c -e 0x00000ef8 -- 5 220 bytes (main)
Debug: data-disassemble -s 0x00000e1c -e 0x00000ef8 -- 5 => Found 83 instructions. 40 with source code, 43 without
Debug-17: Elapsed time for Disassembly Request: 017 ms
disassemble /s 0xd00 0xef8
A syntax error in expression, near `0xef8'.
A syntax error in expression, near `0xef8'. (from interpreter-exec console "disassemble /s 0xd00 0xef8")
disassemble /s 0xd00,0xef8
Dump of assembler code from 0xd00 to 0xef8:
src/dma.c:
16 {
0x00000d00 <DmaStartTransfer+0>: push {lr}
0x00000d02 <DmaStartTransfer+2>: sub sp, #44 ; 0x2c
0x00000d04 <DmaStartTransfer+4>: mov r3, sp
0x00000d06 <DmaStartTransfer+6>: stmia.w r3, {r0, r1}
17 LDMA_TransferCfg_t TxConfig_s = LDMA_TRANSFER_CFG_PERIPHERAL(ldmaPeripheralSignal_USART0_TXBL);
0x00000d0a <DmaStartTransfer+10>: movs r0, #0
0x00000d0c <DmaStartTransfer+12>: str r0, [sp, #24]
0x00000d0e <DmaStartTransfer+14>: str r0, [sp, #28]
0x00000d10 <DmaStartTransfer+16>: str r0, [sp, #32]
0x00000d12 <DmaStartTransfer+18>: str r0, [sp, #36] ; 0x24
0x00000d14 <DmaStartTransfer+20>: ldr r3, [pc, #76] ; (0xd64 <DmaStartTransfer+100>)
0x00000d16 <DmaStartTransfer+22>: str r3, [sp, #24]
18 LDMA_Descriptor_t TxDescriptor_s = LDMA_DESCRIPTOR_SINGLE_M2P_BYTE(Strip_s.Buffer_ps, USART0->TXDATA, Strip_s.Count_u8 * 3);
0x00000d18 <DmaStartTransfer+24>: str r0, [sp, #8]
0x00000d1a <DmaStartTransfer+26>: str r0, [sp, #12]
0x00000d1c <DmaStartTransfer+28>: str r0, [sp, #16]
0x00000d1e <DmaStartTransfer+30>: str r0, [sp, #20]
0x00000d20 <DmaStartTransfer+32>: ldrb.w r3, [sp]
0x00000d24 <DmaStartTransfer+36>: add.w r3, r3, r3, lsl #1
0x00000d28 <DmaStartTransfer+40>: subs r3, #1
0x00000d2a <DmaStartTransfer+42>: ldrh.w r2, [sp, #8]
0x00000d2e <DmaStartTransfer+46>: bfi r2, r3, #4, #11
0x00000d32 <DmaStartTransfer+50>: strh.w r2, [sp, #8]
0x00000d36 <DmaStartTransfer+54>: ldrb.w r3, [sp, #10]
0x00000d3a <DmaStartTransfer+58>: orr.w r3, r3, #16
0x00000d3e <DmaStartTransfer+62>: strb.w r3, [sp, #10]
0x00000d42 <DmaStartTransfer+66>: ldrb.w r3, [sp, #11]
0x00000d46 <DmaStartTransfer+70>: orr.w r3, r3, #48 ; 0x30
0x00000d4a <DmaStartTransfer+74>: strb.w r3, [sp, #11]
0x00000d4e <DmaStartTransfer+78>: str r1, [sp, #12]
0x00000d50 <DmaStartTransfer+80>: ldr r3, [pc, #20] ; (0xd68 <DmaStartTransfer+104>)
0x00000d52 <DmaStartTransfer+82>: ldr r3, [r3, #60] ; 0x3c
0x00000d54 <DmaStartTransfer+84>: str r3, [sp, #16]
19
20 LDMA_StartTransfer(0, &TxConfig_s, &TxDescriptor_s);
0x00000d56 <DmaStartTransfer+86>: add r2, sp, #8
0x00000d58 <DmaStartTransfer+88>: add r1, sp, #24
0x00000d5a <DmaStartTransfer+90>: bl 0xacc <LDMA_StartTransfer>
21 }
0x00000d5e <DmaStartTransfer+94>: add sp, #44 ; 0x2c
0x00000d60 <DmaStartTransfer+96>: ldr.w pc, [sp], #4
0x00000d64 <DmaStartTransfer+100>: movs r2, r0
0x00000d66 <DmaStartTransfer+102>: movs r4, r0
0x00000d68 <DmaStartTransfer+104>: stmia r0!, {}
0x00000d6a <DmaStartTransfer+106>: ands r5, r0
src/ledstrip.c:
7 {
0x00000d6c <StripCreate+0>: push {r3, r4, r5, lr}
0x00000d6e <StripCreate+2>: mov r4, r0
0x00000d70 <StripCreate+4>: mov r5, r1
8 uint8_t* Buffer_ps;
9
10 Buffer_ps = (uint8_t*) calloc(Count, 3);
0x00000d72 <StripCreate+6>: movs r1, #3
0x00000d74 <StripCreate+8>: mov r0, r5
0x00000d76 <StripCreate+10>: bl 0xe88 <calloc>
11 if (Buffer_ps)
0x00000d7a <StripCreate+14>: cbz r0, 0xd84 <StripCreate+24>
12 {
13 Strip_ps->Count_u8 = Count;
0x00000d7c <StripCreate+16>: strb r5, [r4, #0]
14 Strip_ps->Buffer_ps = Buffer_ps;
0x00000d7e <StripCreate+18>: str r0, [r4, #4]
15 return true;
0x00000d80 <StripCreate+20>: movs r0, #1
22 }
23 }
0x00000d82 <StripCreate+22>: pop {r3, r4, r5, pc}
19 Strip_ps->Count_u8 = 0;
0x00000d84 <StripCreate+24>: movs r0, #0
0x00000d86 <StripCreate+26>: strb r0, [r4, #0]
20 Strip_ps->Buffer_ps = NULL;
0x00000d88 <StripCreate+28>: str r0, [r4, #4]
21 return false;
0x00000d8a <StripCreate+30>: b.n 0xd82 <StripCreate+22>
src/main.c:
21 {
0x00000d8c <gpioInit+0>: push {r3, lr}
22 CMU_ClockEnable(cmuClock_GPIO, 1);
0x00000d8e <gpioInit+2>: movs r1, #1
0x00000d90 <gpioInit+4>: movs r0, #58 ; 0x3a
0x00000d92 <gpioInit+6>: bl 0x600 <CMU_ClockEnable>
23
24 GPIO_PinModeSet(gpioPortB, 0, gpioModePushPull, 1);
0x00000d96 <gpioInit+10>: movs r3, #1
0x00000d98 <gpioInit+12>: movs r2, #4
0x00000d9a <gpioInit+14>: movs r1, #0
0x00000d9c <gpioInit+16>: mov r0, r3
0x00000d9e <gpioInit+18>: bl 0x968 <GPIO_PinModeSet>
25 GPIO_PinModeSet(gpioPortB, 1, gpioModeInput, 0);
0x00000da2 <gpioInit+22>: movs r3, #0
0x00000da4 <gpioInit+24>: movs r2, #1
0x00000da6 <gpioInit+26>: mov r1, r2
0x00000da8 <gpioInit+28>: mov r0, r2
0x00000daa <gpioInit+30>: bl 0x968 <GPIO_PinModeSet>
26 }
0x00000dae <gpioInit+34>: pop {r3, pc}
27
28 void spiInit()
29 {
0x00000db0 <spiInit+0>: push {r4, lr}
0x00000db2 <spiInit+2>: sub sp, #32
30 const USART_InitSync_TypeDef Init =
0x00000db4 <spiInit+4>: add.w r12, sp, #4
0x00000db8 <spiInit+8>: ldr r4, [pc, #84] ; (0xe10 <spiInit+96>)
0x00000dba <spiInit+10>: ldmia r4!, {r0, r1, r2, r3}
0x00000dbc <spiInit+12>: stmia.w r12!, {r0, r1, r2, r3}
0x00000dc0 <spiInit+16>: ldmia.w r4, {r0, r1, r2}
0x00000dc4 <spiInit+20>: stmia.w r12, {r0, r1, r2}
31 { \
32 usartEnable, /* Enable RX/TX when initialization is complete. */ \
33 0, /* Use current configured reference clock for configuring baud rate. */ \
34 200000, /* 1 Mbits/s. */ \
35 usartDatabits8, /* 8 databits. */ \
36 true, /* Master mode. */ \
37 true, /* Send least significant bit first. */ \
38 usartClockMode0, /* Clock idle low, sample on rising edge. */ \
39 false, /* Not USART PRS input mode. */ \
40 0, /* PRS channel 0. */ \
41 false, /* No AUTOTX mode. */ \
42 false, /* No AUTOCS mode. */ \
43 false, /* No CS invert. */ \
44 0, /* Auto CS Hold cycles. */ \
45 0 /* Auto CS Setup cycles. */ \
46 };
47
48 CMU_ClockEnable(cmuClock_USART0, 1);
0x00000dc8 <spiInit+24>: movs r1, #1
0x00000dca <spiInit+26>: movs r0, #40 ; 0x28
0x00000dcc <spiInit+28>: bl 0x600 <CMU_ClockEnable>
49
50 GPIO_PinModeSet(LED_CK_PORT, LED_CK_PIN, gpioModePushPull, 0);
0x00000dd0 <spiInit+32>: movs r3, #0
0x00000dd2 <spiInit+34>: movs r2, #4
0x00000dd4 <spiInit+36>: movs r1, #2
0x00000dd6 <spiInit+38>: mov r0, r1
0x00000dd8 <spiInit+40>: bl 0x968 <GPIO_PinModeSet>
51 GPIO_PinModeSet(LED_DO_PORT, LED_DO_PIN, gpioModePushPull, 0);
0x00000ddc <spiInit+44>: movs r3, #0
0x00000dde <spiInit+46>: movs r2, #4
0x00000de0 <spiInit+48>: mov r1, r3
0x00000de2 <spiInit+50>: movs r0, #2
0x00000de4 <spiInit+52>: bl 0x968 <GPIO_PinModeSet>
52
53 GPIO->USARTROUTE[0].ROUTEEN |= GPIO_USART_ROUTEEN_CLKPEN | GPIO_USART_ROUTEEN_TXPEN;
0x00000de8 <spiInit+56>: ldr r3, [pc, #40] ; (0xe14 <spiInit+100>)
0x00000dea <spiInit+58>: ldr.w r2, [r3, #1564] ; 0x61c
0x00000dee <spiInit+62>: orr.w r2, r2, #24
0x00000df2 <spiInit+66>: str.w r2, [r3, #1564] ; 0x61c
54 GPIO->USARTROUTE[0].CLKROUTE = LED_CK_PORT | (LED_CK_PIN << _GPIO_USART_CLKROUTE_PIN_SHIFT);
0x00000df6 <spiInit+70>: mov.w r2, #131074 ; 0x20002
0x00000dfa <spiInit+74>: str.w r2, [r3, #1584] ; 0x630
55 GPIO->USARTROUTE[0].TXROUTE = LED_DO_PORT | (LED_DO_PIN << _GPIO_USART_TXROUTE_PIN_SHIFT);
0x00000dfe <spiInit+78>: movs r2, #2
0x00000e00 <spiInit+80>: str.w r2, [r3, #1588] ; 0x634
56
57 USART_InitSync(USART0, &Init);
0x00000e04 <spiInit+84>: add r1, sp, #4
0x00000e06 <spiInit+86>: ldr r0, [pc, #16] ; (0xe18 <spiInit+104>)
0x00000e08 <spiInit+88>: bl 0xc14 <USART_InitSync>
58 }
0x00000e0c <spiInit+92>: add sp, #32
0x00000e0e <spiInit+94>: pop {r4, pc}
0x00000e10 <spiInit+96>: subs r0, r1, r1
0x00000e12 <spiInit+98>: movs r0, r0
0x00000e14 <spiInit+100>: stmia r0!, {}
0x00000e16 <spiInit+102>: ands r3, r0
0x00000e18 <spiInit+104>: stmia r0!, {}
0x00000e1a <spiInit+106>: ands r5, r0
59
60 int main()
61 {
=> 0x00000e1c <main+0>: push {lr}
0x00000e1e <main+2>: sub sp, #12
src/gecko_sdk_4.0.2\platform\emlib\inc/em_system.h:
391 return (uint8_t)((DEVINFO->INFO & _DEVINFO_INFO_PRODREV_MASK)
0x00000e20 <main+4>: ldr r3, [pc, #88] ; (0xe7c <main+96>)
0x00000e22 <main+6>: ldr r3, [r3, #0]
0x00000e24 <main+8>: ubfx r3, r3, #16, #8
src/gecko_sdk_4.0.2\platform\emlib\inc/em_chip.h:
337 if (SYSTEM_GetProdRev() == 1) {
0x00000e28 <main+12>: cmp r3, #1
0x00000e2a <main+14>: beq.n 0xe52 <main+54>
src/main.c:
65 gpioInit();
0x00000e2c <main+16>: bl 0xd8c <gpioInit>
66 spiInit();
0x00000e30 <main+20>: bl 0xdb0 <spiInit>
67
68 DmaInit();
0x00000e34 <main+24>: bl 0xcdc <DmaInit>
69
70 StripCreate(&Strip_s, 32);
0x00000e38 <main+28>: movs r1, #32
0x00000e3a <main+30>: mov r0, sp
0x00000e3c <main+32>: bl 0xd6c <StripCreate>
73 {
74 DmaStartTransfer(Strip_s);
0x00000e40 <main+36>: add r3, sp, #8
0x00000e42 <main+38>: ldmdb r3, {r0, r1}
0x00000e46 <main+42>: bl 0xd00 <DmaStartTransfer>
75 UDELAY_Delay(1000000);
0x00000e4a <main+46>: ldr r0, [pc, #52] ; (0xe80 <main+100>)
0x00000e4c <main+48>: bl 0xcb4 <UDELAY_Delay>
72 while(1)
0x00000e50 <main+52>: b.n 0xe40 <main+36>
src/gecko_sdk_4.0.2\platform\emlib\inc/em_chip.h:
338 bool hfrcoClkIsOff = (CMU->CLKEN0 & CMU_CLKEN0_HFRCO0) == 0;
0x00000e52 <main+54>: ldr r3, [pc, #48] ; (0xe84 <main+104>)
0x00000e54 <main+56>: ldr r2, [r3, #100] ; 0x64
339 CMU->CLKEN0_SET = CMU_CLKEN0_HFRCO0;
0x00000e56 <main+58>: add.w r3, r3, #4096 ; 0x1000
0x00000e5a <main+62>: mov.w r1, #262144 ; 0x40000
0x00000e5e <main+66>: str r1, [r3, #100] ; 0x64
340 /* Enable HFRCO CLKOUT0. */
341 *(volatile uint32_t*)(0x40012020UL) = 0x4UL;
0x00000e60 <main+68>: add.w r3, r3, #36864 ; 0x9000
0x00000e64 <main+72>: movs r1, #4
0x00000e66 <main+74>: str r1, [r3, #32]
342 if (hfrcoClkIsOff) {
0x00000e68 <main+76>: tst.w r2, #262144 ; 0x40000
0x00000e6c <main+80>: bne.n 0xe2c <main+16>
343 CMU->CLKEN0_CLR = CMU_CLKEN0_HFRCO0;
0x00000e6e <main+82>: sub.w r3, r3, #32768 ; 0x8000
0x00000e72 <main+86>: mov.w r2, #262144 ; 0x40000
0x00000e76 <main+90>: str r2, [r3, #100] ; 0x64
0x00000e78 <main+92>: b.n 0xe2c <main+16>
0x00000e7a <main+94>: nop
0x00000e7c <main+96>: strh r0, [r0, #0]
0x00000e7e <main+98>: lsrs r0, r4, #31
0x00000e80 <main+100>: negs r0, r0
0x00000e82 <main+102>: movs r7, r1
0x00000e84 <main+104>: strh r0, [r0, #0]
0x00000e86 <main+106>: ands r0, r0
unknown:
--- no source info for this pc ---
0x00000e88 <calloc+0>: ldr r3, [pc, #8] ; (0xe94 <calloc+12>)
0x00000e8a <calloc+2>: mov r2, r1
0x00000e8c <calloc+4>: mov r1, r0
0x00000e8e <calloc+6>: ldr r0, [r3, #0]
0x00000e90 <calloc+8>: b.w 0xe98 <_calloc_r>
0x00000e94 <calloc+12>: lsls r4, r2, #16
0x00000e96 <calloc+14>: movs r0, #0
0x00000e98 <_calloc_r+0>: push {r4, lr}
0x00000e9a <_calloc_r+2>: mul.w r1, r2, r1
0x00000e9e <_calloc_r+6>: bl 0xf60 <_malloc_r>
0x00000ea2 <_calloc_r+10>: mov r4, r0
0x00000ea4 <_calloc_r+12>: cbz r0, 0xec2 <_calloc_r+42>
0x00000ea6 <_calloc_r+14>: ldr.w r2, [r0, #-4]
0x00000eaa <_calloc_r+18>: bic.w r2, r2, #3
0x00000eae <_calloc_r+22>: subs r2, #4
0x00000eb0 <_calloc_r+24>: cmp r2, #36 ; 0x24
0x00000eb2 <_calloc_r+26>: bhi.n 0xede <_calloc_r+70>
0x00000eb4 <_calloc_r+28>: cmp r2, #19
0x00000eb6 <_calloc_r+30>: bhi.n 0xec6 <_calloc_r+46>
0x00000eb8 <_calloc_r+32>: mov r2, r0
0x00000eba <_calloc_r+34>: movs r3, #0
0x00000ebc <_calloc_r+36>: strd r3, r3, [r2]
0x00000ec0 <_calloc_r+40>: str r3, [r2, #8]
0x00000ec2 <_calloc_r+42>: mov r0, r4
0x00000ec4 <_calloc_r+44>: pop {r4, pc}
0x00000ec6 <_calloc_r+46>: movs r3, #0
0x00000ec8 <_calloc_r+48>: cmp r2, #27
0x00000eca <_calloc_r+50>: strd r3, r3, [r0]
0x00000ece <_calloc_r+54>: bls.n 0xee8 <_calloc_r+80>
0x00000ed0 <_calloc_r+56>: cmp r2, #36 ; 0x24
0x00000ed2 <_calloc_r+58>: strd r3, r3, [r0, #8]
0x00000ed6 <_calloc_r+62>: beq.n 0xeee <_calloc_r+86>
0x00000ed8 <_calloc_r+64>: add.w r2, r0, #16
0x00000edc <_calloc_r+68>: b.n 0xeba <_calloc_r+34>
0x00000ede <_calloc_r+70>: movs r1, #0
0x00000ee0 <_calloc_r+72>: bl 0x14d4 <memset>
0x00000ee4 <_calloc_r+76>: mov r0, r4
0x00000ee6 <_calloc_r+78>: pop {r4, pc}
0x00000ee8 <_calloc_r+80>: add.w r2, r0, #8
0x00000eec <_calloc_r+84>: b.n 0xeba <_calloc_r+34>
0x00000eee <_calloc_r+86>: add.w r2, r0, #24
0x00000ef2 <_calloc_r+90>: strd r3, r3, [r0, #16]
0x00000ef6 <_calloc_r+94>: b.n 0xeba <_calloc_r+34>
End of assembler dump.
{"output":"","token":34,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
I'm using a simpler project now to make debugging easier, hence the different code and addresses.
But considering that the output of the disassemble command looks fine, I'm pretty sure the issue lies somewhere in rendering the disassembly. When I scroll a few lines up/down and then in the different direction again, the lines that have moved out of view change to be correct. You can see it happening in the recording below:
After hooking the extension up to the debugger, I'm starting to think this may be a bug in VS Code, since I couldn't find anything going wrong in the extension.
And when I look at the DOM of the Disassembly view, I can see a mismatch between the aria-label attribute and the actual text node:
Good detective work! It is still possible that we are doing something wrong. Let us verify that we are sending VSCode a proper response. VSCode is not supposed to interpret what we send or do so minimally. If you put the following in your launch.json, we may be able to see what VSCode requested and what we returned.
"showDevDebugOutput": "vscode",
It should also match the manual disassembly you have done.
After hooking the extension up to the debugger,
When you say that are you actually single-stepping in the extension within VSCode or using the Chrome Debug tools to examine the DOM?
I'm using GCC for ARM. Why would you think otherwise?
Because I saw the .axf extension. Typically used by uVision I think (or IAR). Sure you can use any extension you want with any compiler. IAR does some super aggressive optimizations and re-arranging of the code, where it becomes difficult to read. That doesn't mean it will produce jumbled-up addresses, but can produce jumbled-up source lines
"executable": "${workspaceFolder}/Firmware/build/debug/debug.axf",
Here you go:
From client: disassemble({"memoryReference":"0x00000e1c","offset":0,"instructionOffset":-200,"instructionCount":400,"resolveSymbols":true})
Debug-18: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x00000e1c","offset":0,"instructionOffset":-200,"instructionCount":400,"resolveSymbols":true},"type":"request","seq":18}
26-interpreter-exec console "show architecture"
-> ~"The target architecture is set to \"auto\" (currently \"armv8-m.main\").\n"
-> 26^done
27-interpreter-exec console "info mem"
-> ~"Using memory regions provided by the target.\n"
-> ~"There are no memory regions defined.\n"
-> 27^done
[memory regions redacted]
Debug-18: Dequeuing...
Debug: Gdb command: -data-disassemble -s 0x00000acc -e 0x00000cb4 -- 5 488 bytes (LDMA_StartTransfer)
Suppressing output for '28-data-disassemble -s 0x00000acc -e 0x00000cb4 -- 5'
Debug: Gdb command: -data-disassemble -s 0x00000cb4 -e 0x000014d4 -- 5 2080 bytes (UDELAY_Delay)
Suppressing output for '29-data-disassemble -s 0x00000cb4 -e 0x000014d4 -- 5'
Debug: data-disassemble -s 0x00000acc -e 0x00000cb4 -- 5 => Found 200 instructions. 199 with source code, 1 without
Debug: data-disassemble -s 0x00000cb4 -e 0x000014d4 -- 5 => Found 788 instructions. 185 with source code, 603 without
Debug-18: Elapsed time for Disassembly Request: 516452 ms
To client: {"seq":0,"type":"response","request_seq":18,"command":"disassemble","success":true,"body":{"instructions":[{"address":"0x00000c34","pvtAddress":3124,"instruction":"4ff48061 mov.w\tr1, #1024\t; 0x400","symbol":"USART_InitSync","pvtInstructionBytes":"4f f4 80 61","instructionBytes":"<USART_InitSync+32>","location":{"name":"em_usart.c","path":"C:\\Users\\gietl.jg\\git\\efr32-led\\src\\gecko_sdk_4.0.2\\platform\\emlib\\src\\em_usart.c","sourceReference":0},"line":870,"endLine":871},{"address":"0x00000c38","pvtAddress":3128,"instruction":"0b43 orrs\tr3, r1","symbol":"USART_InitSync","pvtInstructionBytes":"0b 43","instructionBytes":"<USART_InitSync+36>","endLine":871},{"address":"0x00000c3a","pvtAddress":3130,"instruction":"1343 orrs\tr3, r2","symbol":"USART_InitSync","pvtInstructionBytes":"13 43","instructionBytes":"<USART_InitSync+38>","location":{"name":"em_usart.c","path":"C:\\Users\\gietl.jg\\git\\efr32-led\\src\\gecko_sdk_4.0.2\\platform\\emlib\\src\\em_usart.c","sourceReference":0},"line":869,"endLine":869},{"address":"0x00000c3c","pvtAddress":3132,"instruction":"ab60 str\tr3, [r5, #8]","symbol":"USART_InitSync","pvtInstructionBytes":"ab 60","instructionBytes":"<USART_InitSync+40>","endLine":869},{"address":"0x00000c3e","pvtAddress":3134,"instruction":"ab68 ldr\tr3, [r5, #8]","symbol":"USART_InitSync","pvtInstructionBytes":"ab 68","instructionBytes":"<USART_InitSync+42>","location":{"name":"em_usart.c","path":"C:\\Users\\gietl.jg\\git\\efr32-l[...]
From client: disassemble({"memoryReference":"0x00000e1c","offset":0,"instructionOffset":0,"instructionCount":50,"resolveSymbols":true})
Debug-19: Enqueuing {"command":"disassemble","arguments":{"memoryReference":"0x00000e1c","offset":0,"instructionOffset":0,"instructionCount":50,"resolveSymbols":true},"type":"request","seq":19}
Debug-19: Dequeuing...
Debug-19: Elapsed time for Disassembly Request: 72276 ms
To client: {"seq":0,"type":"response","request_seq":19,"command":"disassemble","success":true,"body":{"instructions":[{"address":"0x00000e1c","pvtAddress":3612,"instruction":"00b5 push\t{lr}","symbol":"main","pvtInstructionBytes":"00 b5","instructionBytes":"<main+0>","location":{"name":"main.c","path":"C:\\Users\\gietl.jg\\git\\efr32-led\\src\\main.c","sourceReference":0},"line":60,"endLine":61},{"address":"0x00000e1e","pvtAddress":3614,"instruction":"83b0 sub\tsp, #12","symbol":"main","pvtInstructionBytes":"83 b0","instructionBytes":"<main+2>","endLine":61},{"address":"0x00000e20","pvtAddress":3616,"instruction":"164b ldr\tr3, [pc, #88]\t; (0xe7c <main+96>)","symbol":"main","pvtInstructionBytes":"16 4b","instructionBytes":"<main+4>","location":{"name":"em_system.h","path":"C:\\Users\\gietl.jg\\git\\efr32-led\\src\\gecko_sdk_4.0.2\\platform\\emlib\\inc\\em_system.h","sourceReference":0},"line":391,"endLine":391},{"address":"0x00000e22","pvtAddress":3618,"instruction":"1b68 ldr\tr3, [r3, #0]","symbol":"main","pvtInstructionBytes":"1b 68","instructionBytes":"<main+6>","endLine":391},{"address":"0x00000e24","pvtAddress":3620,"instruction":"c3f30743 ubfx\tr3, r3, #16, #8","symbol":"main","pvtInstructionBytes":"c3 f3 07 43","instructionBytes":"<main+8>","endLine":391},{"address":"0x00000e28","pvtAddress":3624,"instruction":"012b cmp\tr3, #1","symbol":"main","pvtInstructionBytes":"01 2b","instructionBytes":"<main+12>","location":{"name":"em_chip.h","path":[...]
I'm not sure what to make of this though. Yes, I was setting breakpoints and stepping through the extension code and when I checked e.g. the instructions array in disasm.ts:492 everything was in the right order.
I examined the DOM with Chrome Debug tools in addition to that, but I don't know how to debug the client-side/UI code. I'm trying to build VS Code from source now, but it's giving me a headache 😖
I guess this project is using the .axf extension because some developers also use the Silabs IDE, and it's the default there.
Heheh. Yes, building VSCode is a challenge, but hopefully we don't need that.
Lines starting with From client: are requests from VSCode. Lines starting with To client: are a response from the extension back to VSCodel. This is a feature of VSCode. But, it appears that it is truncating the output because it is very large.
Since you are already debugging this extension, could you do the following.
-
Make sure you are debugging both the extension and the debug adapter following the instructions in https://github.com/Marus/cortex-debug#how-to-debug
-
Make the following changes to the code, and set a breakpoint where indicated
-
Make sure you are running the task
npm watchor compile the extension from scratch -
Start debugging the 'Extension+Debug Adapter' config -- this will launch second VSCode instance
-
In the second instance, Start debugging your FW project
-
Invoke a Disassembly
-
You should hit the breakpoint at
disasm.ts:787 -
Examine the Console of the first VSCode instance. Since the first instance is running two debuggers, make sure you select the 'Debug Server' console output. You should see something like this....if you scroll a bit
You can Copy All and paste it into a file and attach it here, but also take a look for yourself what is being sent to VSCode
If you make any changes and re-compile, make sure you completely restart the second VSCode instance. You also have to terminate all debug sessions in the first instance before you restart.
Unfortunately, VS Code is truncating everything that is too large, so this method didn't help. But I found out I can copy the response to the clipboard using copy(response).
Here's the output: https://gist.github.com/gietljohannes/710e0e4d8522d8ab9586f460eb37f380
I also used this code snippet to check if all addresses are in order (they are):
arr = [0];for(i of response.body.instructions) {if(parseInt(i.address) > parseInt(arr[arr.length-1])){arr.push(parseInt(i.address));}else{console.log("Error!");break;}}
Maybe the problem lies in this file ? https://github.com/microsoft/vscode/blob/b30900b56c4b3ca6c65d7ab92032651f4cb23f15/src/vs/workbench/contrib/debug/browser/disassemblyView.ts
Aaaarghhh. I would like to not go into the VSCode code base. In this case, I know who authored it, he may accept a PR.
But, it is still hard to believe that the problem is in VSCode because they don't interpret anything other than the address field. Anything that starts with pvt is for my benefit.
I will review the VSCode implementation tomorrow maybe.
also see this issue w/ v1.12.1, preventing any debug-attempt at assembly-level :( also in my case GDB reports the correct disassembly, but I see mixed lines at the frontend. would be very nice if this one could be fixed.
