I managed to set up a gdbserver for a Qt application and ran it on a 64-bit Ubuntu computer using:
gdbserver <ip>:20000 ./sampleQtApp
And I tried to connect it to using a remote computer of the same network using GDB as follows:
set architecture i386:x86-64:intel
target remote <ip>:20000
It gives me the following output, and I can not figure out why.
(gdb) target remote 10.9.5.79:20000
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
Remote debugging using 10.9.5.79:20000
Remote register badly formatted: T0506:0000000000000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
here: 00000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
(gdb)
What am I doing wrong here?
What is your gdb/gdbserver version? Try a more recent one. Look also this question.
Related
I'm trying to use GDB to debug Qemu running on m68k architecture. I am attempting to make some changes to Qemu source to add some functionality to m68k support, and I am trying to use GDB to test changes I have currently made. Important to note is that I am using Qemu v5.2.0-rc1, as that is the version of Qemu currently utilized in a larger system that I am concurrently working with. Currently, I am using qemu-system-m68k to run buildroot (uClinux kernel) on that architecture, using the "-s -S" options for gdb. In a separate terminal, I am trying to run GDB on that remote target using (gdb) target remote localhost:1234, but I am getting the following error message:
warning: Architecture rejected target-supplied description
The connection to the uClinux Qemu kernel seems to go okay, but I cannot connect to the remote host.
I have tried finding any possible solutions to this problem, including setting the GDB architecture (currently says i386, not sure if this is right), which does not work. I have no idea how to get GDB running on this m68k Qemu emulated Linux kernel, and any help would be great. Thanks!
The error message means that QEMU's gdb stub sent gdb a description of what the CPU is (mostly a list of registers), and gdb didn't understand it. One common cause of this is trying to debug with a gdb for the wrong architecture.
You need to use a gdb which is aware of the the target architecture. On Ubuntu there is a 'gdb-multiarch' package which has a gdb-multiarch binary that knows about more than just x86. Otherwise you might need to build gdb from source. You can check if your gdb knows about m68k by running it with no arguments and typing the command set arch m68k. If it replies The target architecture is assumed to be m68k then it's OK (and your issue is something more complicated); if it gives you an error (eg Undefined item: "m68k") then you need to use a different gdb.
I have been tasked with setting up a development environment for an embedded platform. So far, I have set up a remote build host in NetBeans, which copies all of the source files to the target device, compiles them natively with the GNU toolchain on the device (g++, ld, etc.), and then runs the compiled binary and forwards stdout to the development machine that NetBeans is running on.
What I don't understand is: How does the binary on the build machine know where and when to start/stop if the breakpoints exist only in NetBeans? The build host only required ssh access and a compiling/linking toolchain, but somehow seems to communicate with NetBeans for debugging. A colleague of mine suggested it uses gdbserver, but I have not found any documentation on the NetBeans website about this package, and it is not installed on the build host (at least not from apt). How is NetBeans doing this?
GUI IDE's which use (or can be configured to use) a distinct command-line toolchain for compilation and debug typically do this by running each required toolchain program as a subprocess and interacting with it through standard streams. Essentially, the IDE would use gcc or gdb with the same textual interface used when running it in a terminal window. The IDE uses its knowledge of lines in the source file to configure breakpoints in gdb much as you would while running it by hand.
In your case, the IDE is configured to use a "remote host" for all of this, so instead of being invoked locally, the toolchain is controlled through as ssh session to the remote machine where both building and running occur.
Because the gdb debugger and the target program are running on the same computer, no gdbserver is required.
In the cases where gdb is too large for the target system, gdbserver is a small program which often gets cross-compiled for the target and loaded onto it. This serves as a compact little delegate which talks to the main gdb program running on a build machine via a serial or network connection and performs the raw interaction with processor, memory, and running program on behalf of gdb.
Another possibility is that the gdbserver role is held by a helper program running on the same machine as gdb which instead commands something like a JTAG debug adapter to interact with the target hardware at a lower level. In this case however, the helper program implementing the gdbserver protocol is not usually called "gdbserver" but instead has an implementation specific name, for example openocd.
gdb runs on the target machine. Only communication with gdb (commands etc) goes via net to your local machine. Read gdb documentation if need to know more/
You can do exactly the same - just open the remote terminal , run gdbserver, start gdb and you are done :)
I'm using GDB on my PC to connect to GDBServer on my device (which uses an iMX51) and I can debug fine. But can any of the GDB UIs I've heard about (e.g. in C++ gdb GUI) be used for this?
Thanks for any help.
You can use Eclipse to remote debug using GDB.
Roughly the process looks like this:
Start by install Eclipse CDT.
Install the C/C++ GNU Toolchain Debug Support and Eclipse Debugger for C/C++ add-ins.
Create a debug configuration for your project (Run->Debug Configurations)
Point to the cross compiler's GDB executable(e.g. if you use CodeSourcery that would be bin/xxxx-gdb ).
In the debugger tab select "gdbserver" and enter the remote target details.
Create a gdb init command file to set up your sysroot, library paths, and point gdb to your executable with the file command.
If you google for remote gdb debugging using Eclipse you'll be able to find more information.
I've just spent a whole day trying to find a way to enable GDB debugging from Qt Creator or Eclipse. I learned that there are basically two approaches to launch the target application:
Using ssh (ssh host gdb)
Using gdbserver
I was able to use both approaches to launch gdb remotely and start the application. However, GDB never responds to any breakpoints set in the IDE. Also I can't pause the application to inspect the program state. In Qt Creator I just get an obscure stack trace (I might have been looking at the traces of ssh or gdb actually...).
Can anyone help me to get started?
Progress!
I found that with Qt Creator 2.0 there is an feature called "Attach and debug remote application." It's based on gdbserver. The good thing is that it stops on the IDE's breakpoints. However, there are two issues:
When it hits a breakpoint it only shows assembly code, not the source code.
GDB often quits because of 'signal received'
I should probably mention that the remote executable is compiled with an older version of GCC than the one installed on my local PC. Perhaps some of the problems are related to this.
Update
I should mention that I switched to running cgdb on the remote machine via SSH.
The remote Qt Creator-based solution wasn't stable. GDB tends to quit because of mysterious 'signal received' messages.
So that GDB on your host (the machine you develop and compile on, so where you have Qt Creator) you have to give it access to the "symbol file".
I usually don't use Qt Creator, but GDB and gdbserver directly for cross-compiled programs remote-debugging. You could maybe give this a try to be sure that this works for you and maybe then find the missing option in Qt Creator (or maybe this will help you find what is missing).
On the target machine run:
gdbserver :5000 yourprogram
On the host machine, run gdb and then load the symbol file:
(gdb) symbol-file yourprogram
On GDB on the host machine, you then have to connect to connect GDB to the remote gdbserver:
(gdb) target remote target_ip_address:5000
From then you can use GDB on the host controlling the program on the target.
I hope this helps!
Due to peculiarities in our makefile build system the file references contained in the debugging symbols look like this:
../src/main.cpp
../../src/utils/logger.cpp
This is no problem for GDB, but Qt Creator was unable to map these paths to the actual files. I was able to fix this by adding 'dir' statements in the GDB init file:
dir src
dir src/utils
...
Now it works.
I would like to debug an embedded system containing gdb remotely using some kind of gui (ie like ddd). The embedded system does not have the sources or build symbols. However my local x windows box has. However the execution must happen on the embedded system. How can I from my development box drive gdb remotely with some gui ?
leds and jtag are not an option.
I think, gdbserver could help you.
On Remote target:
target> gdbserver localhost:1234 <application>
On Host (build machine):
host> gdb <application>
Note that the on target may be stripped off from the symbols. But host may have all the symbols.
gdb> set <path-to-libs-search>
gdb> target remote <target-ip>:1234
gdb> break main
gdb> cont
If this works, get some GDB gui on the host machine and try to replicate the same settings. (I have used SlickEdit and eclipse for this purpose).