2
votes

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.)

2
What version of GDB are you running on your host?dbrank0
@dbrank0, GNU gdb (GDB) 7.6.1-ubuntu.Hi-Angel
So it's gdb for your host PC. You need appropriate build for 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).dbrank0
@dbrank0 so, is this means that the gdb and gdbserver should be the same version? Or why am I need to build the gdb too? Right now the gdbserver for a target is built from a sources, and the gdb on a host is the one from Ubuntu repository.Hi-Angel
Yes, while it is possible to build "multiarch" gdb, default Ubuntu gdb (called gdb only) is built to support single architecture - host PC. You need gdb that can debug ARM and is compatible with ABI used on your target.dbrank0

2 Answers

2
votes

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
votes

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.