search

zephyrproject-rtos / sdk-ng

Zephyr SDK (Toolchains, Development Tools)
Apache License 2.0
169 stars 123 forks source link

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

Open hongshui3000 opened 1 year ago

hongshui3000 commented 1 year ago

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. image

hongshui3000 commented 1 year ago

https://github.com/Marus/cortex-debug/issues/780

stephanosio commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago 
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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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)