Is there a UI for GDB that connects to a device? - c++

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.

Related

can't do remote-debugging with j-link in Clion IDE

I am trying to remote-debug a project in Clion but I can't seem to get a working debugging session. I think I've correctly launched my gdb server/client because my gdb client connects to the JLinkGDBServerCL.exe process
and they communicate.However, in clion, I can't break in the source code. The only thing that I get from clion is a disassembly of my program with no symbol at all which is odd because there is a symbol table in the .elf
that I am trying to debug. And one last detail, I can't "step in" the assembly code neither (but I can run commands in the gdb client in Clion).
Here is a picture of my debug configuration : debug config
And here is what I'm talking about when I say I can't get a proper debugging session : "debugging session"
Does anybody know what the problem is ?
System info:
OS: Windows 10
IDE: Clion 2018.1.6
GDB Server: JLinkGDBServerCL.exe
Target: TM4C129 (cortex M4) (no OS, just a firmware)
Program: USBMicroloader.elf (debug mode)
I'm having the same issue. I found that if I add the path to the elf file from the build directory into the "Symbol file" (in the run configuration where you set up the remote gdb connection), it fixes your issue. This seems a bit kludgey, but I haven't been able to find a better solution.
However, the next issue I run into is that I can only run that configuration a single time. When I stop debugging I get a message in the console that reads Remote doesn't know how to detach. Debugger disconnected. The clean and build menu options are greyed out until I restart CLion.

CLion run program in separate system terminal

I have an ncurses program that I'd like to interactively debug using CLion. The problem is that when I run the program in CLion to debug it, the inbuilt console where the program is run doesn't display the output of the ncurses program properly.
I'd like to have the program run in my systems terminal so I can see the output properly whilst debugging the program with CLions debugger.
Is there any way to do this?
The best way to accomplish this is to use GDB now it can be really frustrating to get started so Ill show you how I accomplished it in linux
open a terminal and go to your project debug file and type gdbserver localhost:1234 ./myFile
open clion to myFile project and in the upper right corner you should see a build all (or your projects name) click it and go to "edit configurations"
in the upper left corner you should see a plus sign, click it and press "GDB remote debug"
then in "target remote" type tcp:127.0.0.1:1234
Next in "path mappings" press the plus and type /location/to/file/myFile (same file as in 1.) in both Remote and Location
Press OK and in the upper right corner select the name of the configuration that you just made and press debug
you might need to try to restart the gdbserver one more time for this to work but if you did all the steps above you should see a debug prompt come up and on the terminal you should see your project running.
There are some limitations with this for example you always have to run gdbserver localhost:1234 ./myFile command on your terminal for it to work.
Some Video/documentation that helped me:
Debugging with GDB at 33:35 (Video by JetBrain)
GDB documentation on Jetbrain
I hope this helped :)
In other debuggers, you would do this by running the ncurses application in a terminal, and attaching the debugger to the process using ncurses.
Doing that avoids interference between ncurses (which changes the terminal I/O modes) and the debugger's command-line.
The attach feature is a recently released feature of the CLions debugger:
Further reading:
More power to debug: Attach to local process (January 20, 2016)
CLion 1.2 roadmap (August 31, 2015)
Debugging in CLion (May 8, 2015 )
CLion answers frequently asked questions (September 16, 2014)
Debugging ncurses application with gdb
Using GNU's GDB Debugger:
Debugging Ncurses Programs

Can I use Eclipse CDT to debug a prebuilt C++ executable?

On Linux, I have some C++ programs built with my own makefiles, and I'm looking for some GUI debuggers to debug them at source level.
Previously I use KDbg(2.5.2) on openSUSE(12.3). It works but with some very annoying limitation, e.g., I cannot set a breakpoint when the debugged program is not trapped by Kdbg -- I mean, in order to set a new breakpoint, I have to set it before the program is launched or the program pauses on hitting an already set breakpoint.
Now I try to use Eclipse CDT. I got eclipse-cpp-juno-SR2-linux-gtk.tar.gz but find that I don't know how to load my executable so to start debugging.
I googled with words like 『eclipse debug pre-built C binary』, but few seems to care about this feature.
Can Eclipse CDT really do that? If Eclipse CDT can't, is there any better alternatives to KDbg? Please help.
According to hint from this answer, https://stackoverflow.com/a/248119/151453 , I finally figure out how to do it.
The key point is: In the Eclipse CDT project, create/edit a Launch Configuration so to tell the debugger what executable to load.
Now I have to admit, Eclipse CDT does quite well in C++ code debugging far better than KDbg.
Some screen shot below, on openSUSE 12.3 .
Now we can Run -> Debug (F11)
Debugger automatically pauses the program at main()'s first statement.
The Stand-alone Debugger is an Eclipse application which packages the Eclipse plug-ins from the CDT (C/C++ Development Tools) project into an application that can be started from a command-line script:
bash /path/scripts/cdtdebug.sh -e executable [args]

How to run and debug C++ application in Eclipse that's started with a script?

I'm trying to use Eclipse CDT on Ubuntu for C++ development. I'm working on a large C++ project that leverages Tcl as a scripting language to kick off and control the application.
How can I configure Eclipse to launch the application using shell scripts rather than using a C++ "main" application? The shell scripts launch a Tcl application that in turn calls into the C++ application.
Also, is it possible to debug a C++ application using Eclipse and gdb that's started via a script? If so, how does one go about doing it?
Interesting question. Without being able to provide you a straight solution, but Eclipse (gdb) can be attached to a running program - that may not help in your case.
What about trying to employ some kind of remote debugging? I.e. you start your program with gdb and configure gdb to wait for a remote debugger to attach? The 'remote' debugger will be on your local system, of course.
EDIT:
Start your program via
gdbserver localhost:1234 <executable>
Configure your debug session in Eclipse:
- GDB Hardware Debugging
- I had to select the "Standard GDB Hardware debugging launcher" (Debugger tab at the bottom for Helios)
- Check use remote target: Generic TCP/IP: localhost, port 1234
I didn't manage to resolve symbols yet, that might be a path issue.

Remote GDB debugging

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.