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:

efr32-led-1696583899529

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 watch or 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.

Marus / cortex-debug

Disassembly view showing wrong instructions #935