GDB cooperates with vscode(cortex-debug) disassembly to automatically exit

[hongshui3000]

I break on the C code, when I stop at the breakpoint, I open the disassembly window, and gdb automatically exits. I use "gnu_arm_embedded/bin/arm-none-eabi-gdb.exe" it works fine, the problem occurs when using Zephyr sdk.

[hongshui3000]

Marus/cortex-debug#780

[stephanosio]

There is not enough information in this issue to identify the problem.

Please provide the full log/error messages from GDB (there must be a way to make this plugin not suppress the raw GDB outputs?).

[hongshui3000]

There is not enough information in this issue to identify the problem.

Please provide the full log/error messages from GDB (there must be a way to make this plugin not suppress the raw GDB outputs?).

How can I get the log of gdb? Can configure gdb to enter the mode of outputting its own log?

[stephanosio]

How can I get the log of gdb?

You should consult the Cortex-Debug documentation.

Can configure gdb to enter the mode of outputting its own log?

You can launch the GDB directly and try reproducing the crash (assuming it is a crash).

[hongshui3000]

How can I get the log of gdb?

You should consult the Cortex-Debug documentation.

Can configure gdb to enter the mode of outputting its own log?

You can launch the GDB directly and try reproducing the crash (assuming it is a crash).

debug console log
LOG.txt

cortex-debug-server-exiting.log

[2022-12-02T06:54:54.177Z] ppid=20684 pid=20684 OCEAN JLink Launch: ******* Starting new session request type="launch"
[2022-12-02T06:54:54.256Z] ppid=20684 pid=5844 GDB started ppid=20684 pid=5844
[2022-12-02T06:55:01.767Z] ppid=20684 pid=5844 GDB: exited
[2022-12-02T06:55:01.768Z] ppid=20684 pid=5844 OCEAN JLink Launch: quitEvent: Killing server
[2022-12-02T06:55:01.769Z] ppid=20684 pid=5844 GDBServer(21640): forcing an exit with kill()
[2022-12-02T06:55:01.781Z] ppid=20684 pid=5844 OCEAN JLink Launch: quitEvent: sending VSCode TerminatedEvent
[2022-12-02T06:55:01.787Z] ppid=20684 pid=5844 GDBServer(21640): exited code=null signal=SIGTERM
[2022-12-02T06:55:01.828Z] ppid=20684 pid=5844 OCEAN JLink Launch: Begin disconnectRequest

I didn't see gdb crash, but it just quit, after multiple disassembly requests

[hongshui3000]

Debug-146: Dequeuing...
Debug: Gdb command: -data-disassemble -s 0x00000424 -e 0x00000b94 -- 5     1904 bytes  (z_cbvprintf_impl)
Suppressing output for '239-data-disassemble -s 0x00000424 -e 0x00000b94 -- 5'
Debug: Gdb command: -data-disassemble -s 0x00000b94 -e 0x00000bb0 -- 5       28 bytes  (arch_cpu_idle)
Debug: Gdb command: -data-disassemble -s 0x00000bb0 -e 0x00000c5c -- 5      172 bytes  (z_arm_fatal_error)
Debug: Gdb command: -data-disassemble -s 0x00000c5c -e 0x00000d08 -- 5      172 bytes  (z_arm_prep_c)
Debug: Gdb command: -data-disassemble -s 0x00000d08 -e 0x00000d28 -- 5       32 bytes  (z_arm_svc)
Debug: Gdb command: -data-disassemble -s 0x00000d28 -e 0x00000dac -- 5      132 bytes  (arch_new_thread)
Debug: Gdb command: -data-disassemble -s 0x00000dac -e 0x00000dc8 -- 5       28 bytes  (z_arm_exc_exit)
Debug: Gdb command: -data-disassemble -s 0x00000dc8 -e 0x00000fa0 -- 5      472 bytes  (usage_fault.constprop.0)
Suppressing output for '240-data-disassemble -s 0x00000b94 -e 0x00000bb0 -- 5'
Debug: data-disassemble -s 0x00000424 -e 0x00000b94 -- 5 => Found 715 instructions. 715 with source code, 0 without
Suppressing output for '241-data-disassemble -s 0x00000bb0 -e 0x00000c5c -- 5'
Debug: data-disassemble -s 0x00000b94 -e 0x00000bb0 -- 5 => Found 10 instructions. 9 with source code, 1 without
Suppressing output for '242-data-disassemble -s 0x00000c5c -e 0x00000d08 -- 5'

Under the gdb console, as long as I execute the following command, gdb will exit

-data-disassemble -s 0x00000c5c -e 0x00000d08 -- 5

I can't understand why there is a issue with the disassembly of z_arm_prep_c, but there is no problem with the disassembly of other functions

[hongshui3000]

I have no issue reading this code data under the gdb console

x /1x 0x00000c5c
From client: evaluate({"expression":"x /1x 0x00000c5c","frameId":256,"context":"repl"})
70-interpreter-exec console "x /1x 0x00000c5c"
-> ~"0xc5c <z_arm_prep_c>:\t0x4b09b508\n"
0xc5c <z_arm_prep_c>:	0x4b09b508
-> 70^done
To client: {"seq":0,"type":"response","request_seq":50,"command":"evaluate","success":true,"body":{"result":"{\"output\":\"\",\"token\":70,\"outOfBandRecord\":[],\"resultRecords\":{\"resultClass\":\"done\",\"results\":[]}}","variablesReference":0}}
{"output":"","token":70,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}
x /1024x 0x00000c5c 
From client: evaluate({"expression":"x /1024x 0x00000c5c ","frameId":256,"context":"repl"})
71-interpreter-exec console "x /1024x 0x00000c5c "
-> ~"0xc5c <z_arm_prep_c>:\t0x4b09b508\t0xf0234a09\t0xf0234360\t0x6093037f\n"
0xc5c <z_arm_prep_c>:	0x4b09b508	0xf0234a09	0xf0234360	0x6093037f
-> ~"0xc6c <z_arm_prep_c+16>:\t0x8f4ff3bf\t0x8f6ff3bf\t0xfb2ef001\t0xff82f001\n"
0xc6c <z_arm_prep_c+16>:	0x8f4ff3bf	0x8f6ff3bf	0xfb2ef001	0xff82f001
-> ~"0xc7c <z_arm_prep_c+32>:\t0xfa74f000\t0xfb68f001\t0x00000000\t0xe000ed00\n"
0xc7c <z_arm_prep_c+32>:	0xfa74f000	0xfb68f001	0x00000000	0xe000ed00
-> ~"0xc8c <arch_swap>:\t0x490a4a09\t0x68096893\t0x66d96698\t0x684b4908\n"
0xc8c <arch_swap>:	0x490a4a09	0x68096893	0x66d96698	0x684b4908
-> ~"0xc9c <arch_swap+16>:\t0x5380f043\t0x2300604b\t0x8811f383\t0x8f6ff3bf\n"
0xc9c <arch_swap+16>:	0x5380f043	0x2300604b	0x8811f383	0x8f6ff3bf
-> ~"0xcac <arch_swap+32>:\t0x6ed86893\t0xbf004770\t0x4004017c\t0x000045ac\n"

But as long as the disassembly start address is 0x00000c5c, gdb will exit
-data-disassemble -s 0x00000c5c -e ”any address“ -- 5

[stephanosio]

But as long as the disassembly start address is 0x00000c5c, gdb will exit

Are you able to reproduce this using any of the emulation targets (e.g. qemu_cortex_m3)?

Also have you tried reproducing this on a Linux system to see if this is an issue with the Windows build of Zephyr SDK GDB?

[hongshui3000]

Are you able to reproduce this using any of the emulation targets (e.g. qemu_cortex_m3)?
Also have you tried reproducing this on a Linux system to see if this is an issue with the Windows build of Zephyr SDK GDB?

I only tested on windows(win10)

[hongshui3000]

zephyr gdb (2022)
disassemble function(z_arm_prep_c)

E:\work>"C:/Users/yxh/.zephyrtools/toolchain/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb.exe" 
GNU gdb (Zephyr SDK 0.15.1) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-host_w64-mingw32 --target=arm-zephyr-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/zephyrproject-rtos/sdk-ng/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target extended-remote localhost:50000
Remote debugging using localhost:50000
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x10000de2 in ?? ()
(gdb) disassemble /r 0x10000ef0,0x10000f10
Dump of assembler code from 0x10000ef0 to 0x10000f10: --------------------->disassemble function(z_arm_svc) work fine
   0x10000ef0:  1e f0 04 0f     tst.w   lr, #4
   0x10000ef4:  0c bf   ite     eq
   0x10000ef6:  ef f3 08 80     mrseq   r0, MSP
   0x10000efa:  ef f3 09 80     mrsne   r0, PSP
   0x10000efe:  81 69   ldr     r1, [r0, #24]
   0x10000f00:  11 f8 02 1c     ldrb.w  r1, [r1, #-2]
   0x10000f04:  02 29   cmp     r1, #2
   0x10000f06:  ff d0   beq.n   0x10000f08
   0x10000f08:  01 b5   push    {r0, lr}
   0x10000f0a:  41 f0 d4 f8     bl      0x100420b6
   0x10000f0e:  01 bd   pop     {r0, pc}
End of assembler dump.
(gdb) disassemble /r 0x10000e3c,0x10000f10 ---------->disassemble function(z_arm_prep_c) Abnormal exit
Dump of assembler code from 0x10000e3c to 0x10000f10:

Works fine with the 2021 version of gdb

E:\work\>"C:/gnu_arm_embedded/bin/arm-none-eabi-gdb.exe"                                                     
C:\gnu_arm_embedded\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
GNU gdb (xPack GNU Arm Embedded GCC x86_64) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target extended-remote localhost:50000
Remote debugging using localhost:50000
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x10000de2 in ?? ()
(gdb) disassemble /r 0x10000e3c,0x10000f10-------------------------------------->work fine
Dump of assembler code from 0x10000e3c to 0x10000f10:
   0x10000e3c:  08 b5   push    {r3, lr}
   0x10000e3e:  09 4b   ldr     r3, [pc, #36]   ; (0x10000e64)
   0x10000e40:  09 4a   ldr     r2, [pc, #36]   ; (0x10000e68)
   0x10000e42:  23 f0 60 43     bic.w   r3, r3, #3758096384     ; 0xe0000000
   0x10000e46:  23 f0 7f 03     bic.w   r3, r3, #127    ; 0x7f
   0x10000e4a:  93 60   str     r3, [r2, #8]
   0x10000e4c:  bf f3 4f 8f     dsb     sy
   0x10000e50:  bf f3 6f 8f     isb     sy
   0x10000e54:  40 f0 e8 f9     bl      0x10041228
   0x10000e58:  40 f0 de fe     bl      0x10041c18
   0x10000e5c:  00 f0 88 f9     bl      0x10001170
   0x10000e60:  40 f0 26 fa     bl      0x100412b0
   0x10000e64:  00 02   lsls    r0, r0, #8
   0x10000e66:  00 10   asrs    r0, r0, #32
   0x10000e68:  00 ed 00 e0     stc     0, cr14, [r0, #-0]
   0x10000e6c:  0a 4a   ldr     r2, [pc, #40]   ; (0x10000e98)
   0x10000e6e:  0b 49   ldr     r1, [pc, #44]   ; (0x10000e9c)
   0x10000e70:  93 68   ldr     r3, [r2, #8]
   0x10000e72:  09 68   ldr     r1, [r1, #0]

It seems that gdb has issues parsing the following instructions, the latest gdb

0x10000e3c: 08 b5 push {r3, lr}
0x10000e3e: 09 4b ldr r3, [pc, #36] ; (0x10000e64)
0x10000e40: 09 4a ldr r2, [pc, #36] ; (0x10000e68)