debuggin raspberry pi pico加载其他文件？
我正在尝试使用OpenOCD + Picoprobe调试Raspberry Pi Pico项目。我经历了从我的Linux PC完成所有这些操作的步骤（使用PICO和C ++指南开始使用Raspberry Pi，但是PC上有一些教程），但是当试图在GDB中设置断点时，它似乎正在查看另一个文件。
我的步骤是：
在控制台中，导航到OpenOCD文件夹并运行：sudo src/openocd -s tcl/-f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
我只会收到信息消息，没有错误，直到它等待GDB连接
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
，然后在另一个控制台中连接到我想调试的内容，在这种情况下为blink.c示例。我用.efl文件站在构建文件夹中，并运行
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
15是一条相关的可辩论线路。但是事实是，断点被认为是在另一个文件中设置的：
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
然后，所有断点也设置在此处。这是试图设置3个不同断点的示例：
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
这样。我完全迷失在这里发生的事情。谁能指出我为什么会发生这种情况，或者该文件有什么？
I'm trying to debug a Raspberry Pi Pico project using openOCD + Picoprobe. I go through the steps that appear to be correct to do all this from my Linux PC (the Get started with Pico and C++ guide is for the Raspberry Pi, but there are tutorials online for PC), but when trying to set breakpoints in gdb, it appears to be looking at a different file.
My steps are the following:
In a console, navigate to the openOCD folder and run:sudo src/openocd -s tcl/ -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
I get only info messages, no errors, until it waits for the gdb to connect
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Then, in a different console, I navigate to what I want to debug, in this case the blink.c example. I stand inside the build folder with my .elf file and run
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
where 15 is a relevant debuggable line. But the thing is, the breakpoints are said to be set in a different file:
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
and then on, all breakpoints are also set there. Here's an example trying to set 3 different breakpoints:
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
So that. I am totally lost on what's happening here. Could anyone point me to why this is happening, or what that file does?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我看到已经几个月了，但是我遇到了同样的问题，这就是我学到的。
当您编译要调试的C/C ++程序时，您需要在调试模式下编译它，该模式告诉编译器在程序中包含调试符号。如果直接使用GCC编译，则可以使用
-G标志。但是，我假设您正在使用cmake，在这种情况下，您只需添加set（cmake_build_type debug）> cmakelists.txt（在这里找到了其他一些选项）可能不用说，但是在以这种方式进行重新编译后，您需要通过握住bootsel按钮并将其直接插入计算机（即，不是通过调试器PICO）来将新程序重新加载到目标PICO中。
我还发现，在执行此操作之后，将断点设置为仍然没有预期的特定行，我也必须实际指定文件的名称，例如：
break main.c：15I see it's been a few months but I just ran into the same problem, here's what I've learned.
When you compile the C/C++ program that you're trying to debug, you need to compile it in debug mode, which tells the compiler to include debug symbols in the program. If compiling directly with gcc, you can use the
-gflag. However, I'm assuming you're using CMake, in which case you can just addset(CMAKE_BUILD_TYPE Debug)to your CMakeLists.txt (found a few other options here as well)Probably goes without saying, but after recompiling this way, you'll need to re-load your new program onto your target Pico by holding the bootsel button and plugging it into your machine directly (ie. not via your debugger Pico).
I also found that after doing this, setting breakpoints just to specific lines still didn't behave as expected, and I had to actually specify the name of the file as well, ex:
break main.c:15