Gdb

需求 最近使用 stm32u575 芯片的时候，调试时发现很尴尬的问题， jlink 必须安装高版本，然后盗版的就不能用了。MDK 可以直接使用 DAPLink，但是 stm32cubeide 不能直接支持。所以需要想办法解决这个问题。 解决 参考了网上的资料，st 自带的 openocd 不能用，端口不对。 openocd 需要下载官方的 openocd，不要使用 stm32cubeide 自带的。下载地址: https://gnutoolchains.com/arm-eabi/openocd/ 。下载后自行安装。 配置 openocd stm32cubeide 菜单栏 -> Run -> External Tools -> External Tools Configrations -> Program 右键 -> New Configration. Name 自己输入。 Location: 选择刚才下载的 openocd 中的 openocd.exe 所在路径。 Arguments: -f interface\cmsis-dap.cfg -f target\stm32u5x.cfg apply 然后 Run. 配置 debug Run -> Debug Configurations -> GDB Hardware Debugging 右键 -> New Configuratin....

需求 程序崩溃后，希望知道程序到底是因为什么崩溃的，首先需要找到崩溃后的 core 文件，然后调试加载 core 文件。 解决 先在软件的目录寻找 core 文件，如果没有按照下面的步骤来处理。 确认开启了 core 查看当前允许的 core 文件的最大大小。 ulimit -c 设定固定值或者不限制, 单位是 KB ulimit -c 1024 ulimit -c unlimited 确认 core 文件路径 如果文件路径类似下面这样的，就说明 core 被系统转存了，需要专门导出 cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e 导出 core 导出需要使用 coredumpctl, 如果没有安装，使用如下命令: sudo apt install systemd-coredump 使用 coredumpctl, 查看崩溃的 pid, 如果显示的不完整，可以使用方向键来查看未完信息。 如果崩溃的 pid 为 1234， 并且导出的文件名为 core_2023 coredumpctl -o core_2023 dump 1234 加载 core 如果可执行文件名为 main, 崩溃文件为 core_2023....

需求 当多个文件编译后，需求调试的时候，需要 b 来打断点，但是前提是通过 list 翻到代码所在行。默认的 list 每次的行数太少，而且也不是一下子就能翻到。 解决 指定文件 可以直接指定源文件的某一行进行 list. 比如需要查看 a.cpp 的 100行。 gdb> list a.cpp:100 指定函数 可以直接指定查看某个函数，比如查看 Pack 这个函数。 gdb> list Pack 参考 gdb中list用法 GDB单步调试程序