编译会导致GDB 调试器在错误的地址启动
我用 Python 开发一个自动化测试脚本，用于测试运行在 STM32L496RG 嵌入式软件。我用 ST 的无界面 GDB 调试器。这个测试需要在测试过程中通过 Python 脚本对源代码进行小幅修改，我已经成功实现了这一点。运行自动化测试脚本时，我能够修改代码、重新构建程序并执行测试步骤，第一次测试通常能成功，但之后就不行了。然后，我必须断开调试器连接，甚至可能需要重新上电 MCU，为下一个需要修改更多代码的测试步骤做准备。第二次修改代码并重新构建后，我尝试启动调试器，调试器似乎成功连接了目标设备。我通过确认 GDB 服务器与目标设备连接、GDB 客户端启动并加载正确的 elf 文件，以及服务器和客户端成功建立链接来验证这一点。
但问题是：第一次程序正确启动时，调试器会显示它等待继续执行的起始地址（如预期）是复位处理程序：Reset_Handler () at ..\Startup/startup_stm32l496rgtx.s:6363 ldrsp, =_estack /* Atollic update: set stack pointer */而第二次重新编译后，调试器显示程序执行的起始地址是：0x08019670 in Eeprom_Format () at ../Src/Eeprom.c:8282 nStatus = Nvm_WriteLong(eepromBaseAddress, NVM_FORMAT_HEADER)。../Src/Eeprom.c 是工作空间中另一个项目的源文件，并不属于当前项目。这个其他项目仅用于为当前项目初始化 EEPROM。当我使用 STM32CubeIDE 图形界面编译并运行相同代码时，一切正常。工作空间中确实有多个项目，但我不明白它们如何干扰，因为 GDB 调试器在设置时确认指向了正确的 elf 文件路径。是否应该在启动调试器之前进行全擦除？这看起来是编译问题还是调试器问题？
页:
[1]