Comments (13)
haneefdm
commented on July 28, 2024
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?
from cortex-debug.
haneefdm
commented on July 28, 2024
The initial currenty highlighted line is where your pc is as shown in the stackframe window.
from cortex-debug.
gietljohannes
commented on July 28, 2024
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
from cortex-debug.
haneefdm
commented on July 28, 2024
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.
from cortex-debug.
haneefdm
commented on July 28, 2024
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.
from cortex-debug.
gietljohannes
commented on July 28, 2024
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:
from cortex-debug.
gietljohannes
commented on July 28, 2024
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:
from cortex-debug.
haneefdm
commented on July 28, 2024
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?
from cortex-debug.
haneefdm
commented on July 28, 2024
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",
from cortex-debug.
gietljohannes
commented on July 28, 2024
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.
from cortex-debug.
haneefdm
commented on July 28, 2024
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.
from cortex-debug.
gietljohannes
commented on July 28, 2024
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
from cortex-debug.
haneefdm
commented on July 28, 2024
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.
from cortex-debug.
Related Issues (20)
- preAttachCommands list executed after GDB connect to GDB Server (openOCD) HOT 1
- Fails to load SEGGER GDB from container. 'Unspecified'.GDBServer will be closed... HOT 7
- Unexpected "monitor reset halt" after "-target-download" HOT 3
- Suspend watchdog counters while halted on a breakpoint HOT 4
- A serious error occurred with gbd: unable to contininue or interrupt HOT 5
- Stepping through code kills the debug session HOT 3
- RTT logs are not printed to terminal HOT 4
- rust debug error if add hw watchpints and triggered HOT 1
- blank output in the RTT terminal HOT 2
- V1.12.1 does not kill openocd process after pressing stop button (Inside Devcontainer) HOT 1
- Custom GDB Server Path HOT 1
- `cortex-debug.openocdPath` Written to `settings.json` or `.code-workspace` file when VSCode Opens HOT 4
- elf not refreshed when restarting debugger after build HOT 8
- st-util fails to start, conditionally HOT 1
- [RFC] Support west debug HOT 11
- Using a custom GDB server HOT 1
- STM32 device. Flash and debug an application with code in internal and external flash HOT 3
- Issues with JTAG and RISC-V target HOT 5
- Is there a way to disable GDB log files from cortex debug? HOT 5
- No option to disable a monitor reset after download HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cortex-debug.