arm-none-eabi-gdb 和 openocd:对偏移查询 qOffsets 的响应格式错误?
我尝试使用 GDB 使用 OpenOCD 和 GNU ARM 工具链(随 MacPorts 安装)调试 Stellaris LM3S8962 评估板,每当我在 GDB 中设置远程目标时,它总是返回“Malfomred 对偏移查询的响应,qOffsets”。关于可能出什么问题的任何想法吗?我有什么遗漏的吗?
[bcochran@narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
>
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets
这是 openocd 输出...一旦遇到格式错误的响应 openocd 就会断开 telnet 连接...
[bcochran@narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection
这是我的 arm-none-eabi-* 工具链的版本输出...
[bcochran@narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)
[bcochran@narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
我能够使用工具链进行编译,并使用 OpenOCD 刷新生成的 .bin 文件。仅通过搜索网络,我无法找到“格式错误的响应”问题的解决方案。
预先感谢您的任何建议或帮助!
更新
感谢@turbo-j 和@guy-sirton 的回答,我能够取得进一步的进展...到目前为止最有帮助的是我确实使用了错误的端口(4444 而不是 3333),但现在我是无论我是否将 -c "init" -c "halt" -c "resethalt"
添加到我的 openocd 命令字符串中,都会得到以下信息:(
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001
这位于 qOffsets 之后req/resp,现已通过)
在 OpenOCD 方面:
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection
有时在 OpenOCD 控制台上出现未定义的调试原因 6 - 目标需要重置
...不确定现在发生了什么,但似乎更接近功能
更新2
看来,如果我不加载文件“main.axf”或“main.o”,我不会遇到远程“g”数据包回复太长
,但我没有得到任何符号...我注意到了其他网站主要处理 .elf 扩展名。有什么区别?我使用 StellarisWare 中的“Hello World”示例,它从 make
命令生成 main.axf、main.bin(闪存写入和运行良好)、main.d、main.o。我的 Makefile 有什么奇怪的吗?
I am attempting to use GDB to debug a Stellaris LM3S8962 Evaluation board using OpenOCD and the GNU ARM toolchain (installed with MacPorts), whenever I set the remote target in GDB it always returns "Malfomred response to offset query, qOffsets". Any ideas on what could be going wrong? Is there anything that I am missing?
[bcochran@narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
>
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets
Here is the openocd output... as soon as the malformed response comes across openocd drops the telnet connection...
[bcochran@narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection
Here are the version outputs of my arm-none-eabi-* toolchain...
[bcochran@narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)
[bcochran@narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
I am able to compile using the toolchain, and flash the resultant .bin file using OpenOCD. I have been unable to find a solution to the "malformed response" issue just by searching the web.
Thanks in advance for any advice or assistance!
UPDATES
Thanks to answers from @turbo-j and @guy-sirton, I was able to progress a bit further... The most helpful thus far was that I was indeed using the wrong port (4444 instead of 3333) but now I am getting the following whether I add -c "init" -c "halt" -c "reset halt"
to my openocd command string or not:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001
(this is right after the qOffsets req/resp, which now passes)
On the OpenOCD side:
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection
With sometimes a undefined debug reason 6 - target needs reset
on the OpenOCD console...not sure what is going on now but it seems closer to functioning
UPDATES 2
It seems if I do not load the file 'main.axf' or 'main.o' I do not run into the Remote 'g' packet reply is too long
but I get no symbols... I've noticed other websites deal primarily with the .elf extension. What is the difference? I'm using the "Hello World" example from StellarisWare which it generates main.axf, main.bin (flash writes and runs fine), main.d, main.o from the make
command. Something odd about my Makefile?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是一个类似于 @athquad 提到的补丁。请参阅他的回答以获取更多信息。感谢他有效地将我指向正确的位置,并且确实为没有提供补丁而提供了很大的耻辱。 :-P
http://pastebin.com/rdFF2eZd
针对 openocd 提交的补丁 631b80fd0835055bb385314f569f589b99d7441d
使用:(./配置选项取决于 jtag 硬件)
Here is a patch like what @athquad mentioned. See his answer for more information. Thanks to him for efficiently pointing me at the right spot, and great shame indeed for offering a patch without providing it. :-P
http://pastebin.com/rdFF2eZd
Patch was made against openocd commit 631b80fd0835055bb385314f569f589b99d7441d
To use: (./configure options depend on jtag hardware)
您使用了错误的端口。使用
目标远程本地主机 3333
进行 GDB 到 OpenOCD 的连接。端口 4444 用于通过终端进行人机交互,并且除了 GDB 连接之外还可以使用。You used the wrong port. Use
target remote localhost 3333
for the GDB-to-OpenOCD connection. The port 4444 is intended for human interaction via a terminal and can be used in addition to a GDB connection.如果你不想编译 OpenOCD,如 tacos' & atquad 的答案是,您可以使用旧版本的 GNU ARM 工具链(例如 7.2.5 就可以)。
(预编译的 0.4.0 和 0.5.0 windows 都会出现这个问题)。
If you don't want to compile OpenOCD, as tacos' & atquad's answer, you can use an older release of the GNU ARM tool chain (7.2.5 is fine for example).
(0.4.0 and 0.5.0 windows precompiled are both giving this problem).
我刚刚遇到了同样的“'g'数据包回复太长”错误并追踪了其原因。
似乎很长一段时间以来,GNU ARM 工具都使用带有 9 个过时浮点寄存器的 ARM 模型。 OpenOCD 对此很明智,并响应 GDB 的寄存器请求提供虚拟值。然而,最近的 eabi 工具链(包括 GDB)已经更新,因此您的 GDB 不再需要这些寄存器 - 因此会出现该消息。
在 OpenOCD 源代码中,我在armv7m.c中修补了armv7m_get_gdb_reg_list()以使其工作,但是我的补丁不够智能,无法知道正在使用哪个GDB版本 - 它只是使用#ifdef开关 - 所以它需要一点与 OpenOCD 源代码集成还有更多工作。
任何需要的人都可以使用补丁。
I have just encountered the same "'g' packet reply is too long" bug and traced it to its cause.
It seems that for a very long time GNU ARM tools have used an ARM model with 9 obsolete floating point registers. OpenOCD is wise to this and in response to GDB's register request supplies dummy values. However, recent eabi toolchains including GDB have come up to date and so your GDB no longer expects these registers - hence the message.
In the OpenOCD source I have patched armv7m_get_gdb_reg_list() in armv7m.c to make this work, but my patch isn't smart enough to know which GDB version is being used - it simply uses an #ifdef switch - so it would need a bit more work to integrate with the OpenOCD source code.
A patch could be available to anyone who wants.
我在 ARM 上进行了大量远程调试,但使用的是不同的处理器、操作系统和工具链:-) 尽管如此,这里还是有一些想法。
这个建议:
来自这里:
http://michaldemin.wordpress。 com/2010/02/22/part-2-debugging-with-gdb-and-openocd/
否则:
远程之间的远程 gdb 协议不匹配和你的 gdb。您可以尝试使用不同版本的工具链。 Google 并找到对其他人有效的方法。
沟通问题。尝试降低波特率?确保串口参数正确。
I do a lot of remote debugging on ARM but with a different processor, OS, and toolchain :-) Nevertheless, here are some thoughts.
This suggestion:
Comes from here:
http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/
Otherwise:
A mismatch in the remote gdb protocol between the remote and your gdb. You can try going to a different version of the toolchain. Google and find what works for others.
A communication issue. Try lower baud rate? Make sure the serial port parameters are sound.