GDB remote debug: can't stop the thread

情到浓时终转凉″ 提交于 2019-12-02 04:19:03

问题


I have a gdbserver on a target, that I launch like gdbserver :2345 /bin/ls. Next I am connect a gdb from a host, and trying issue next commands:

(gdb) target remote 192.168.1.2:2345
Remote debugging using 192.168.1.2:2345
warning: Architecture rejected target-supplied description
[New Thread 686]
(gdb) Remote 'g' packet reply is too long: 00000000c10ed6be0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d00dd6be0000000030fe0d40100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb) i thr
  Id   Target Id         Frame 
* 1    Thread 686        (running)
(gdb) interrupt
(gdb) interrupt 1
(gdb) interrupt 2
(gdb) i thr
  Id   Target Id         Frame 
* 1    Thread 686        (running)
(gdb) bt
Target is executing.
(gdb) c
Continuing.
Cannot execute this command while the selected thread is running.

I thought that may be the reason of a broken gdb is the weird message, tried to Google. Found two assumptions. Here's a man supposes that the gdb (despite IMHO that on the target is running the gdbserver that should send an abstract arch-independent commands) need the architecture that it is debugs to be set. But it doesn't work:

(gdb) set architecture armv7-a
Undefined item: "armv7-a".
(gdb) set architecture armv7
Undefined item: "armv7".
(gdb) set architecture armv5te
Undefined item: "armv5te".

I didn't found any command that could list supported architectures. The second assumption was that the gdbserver itself needs to be configured with a mythological option --with-expat. But... configure: WARNING: unrecognized options: --with-expat

I have no more ideas. So, do anybody knows: how to interrupt the thread on the target?(Btw, breakpoints could be set just fine, but it doesn't help at all, because seems that the gdb is lying about a running thread. If the thread would running, the being debugged ls just gone immediately.)


回答1:


While it is possible to build "multiarch" gdb, default Ubuntu GDB (called gdb) is built to support single architecture - host PC. You can not debug other CPUs with it, although it does connect to any gdbserver.

You need gdb that can debug your target (ARM) and is compatible with ABI used on your target.

You should get that with your toolchain, but if not, it's not hard to build from source. See sourceware.org/gdb/wiki/BuildingCrossGDBandGDBserver for brief instructions.




回答2:


In order to check which architecture your GDB currently support (those you can have in a set architecture command), just type:

(gdb) set architecture

without any arguments... As simple as that. Otherwise, you'll probably need a cross GDB, as mentioned by @drbank0.



来源:https://stackoverflow.com/questions/24669864/gdb-remote-debug-cant-stop-the-thread

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!