I've hard talk on the stream about various Linux debuggers. All of the ones so far have been part of some IDE or another.

I tried some of the standalone debuggers available on Linux, and they all suck. I tried Nemiver, which for some reason collapses your watch variables on each step, and then you have to unhide them each time. Red Hat's Insight had similar problems. cgdb didn't seem to have a window for displaying variables.

The only remotely usable one I found was ddd. I'm wondering if anyone here has used it?

Here's some of the cool features about it:

Executes external binaries (since it's not an IDE it executes anything compiled with gcc).

Keeps variables displayed as you step through the program.

Has a nifty display for variables and even memory contents. DDD can draw a diagram of your data structures, basically.

It has some issues as well:

For some reason it hides out-of-scope variables and brings them back when they come back into scope, which messes up your layout.

The layout code is also a little finicky.

It's ugly as sin.

It can be a little hard to use, since it's based on the old X way of interacting with GUIs.

I'm wondering if anyone has used it, and have any opinions to add? Perhaps someone knows of a really nice standalone debugger?

Casey, have you checked out DDD?

The Handmade Penguin guide recommends KDevelop:
http://davidgow.net/handmadepenguin/ch1.html

It's a full-fledged IDE, but can be launched from the command-line in "debugger-mode":

$ kdevelop --debug gdb PATH_TO_EXECUTABLE

I'm trying it now and it kind of works. Has a few weird bugs (like not allowing me to remove the breakpoint from the program's entry point, instead opening an empty assembly tab), but it was servicable.

The Eclipse IDE, which is usually used for Java development, has a plugin for C/C++ development called CDT. The latest version comes with a wrapper script - cdtdebug.sh - that launches it in "debugger-mode":

https://wiki.eclipse.org/CDT/StandaloneDebugger

I haven't tried it yet since Ubuntu 14.10 comes with an older version.

Thanks, salty-horse. Those are a bit too heavy for me (I've used them in the past), but hopefully others will find them helpful :)

To the best of my knowledge, I have tried every debugger on Linux that allows debugging of an externally-built executable. They are all awful.

Currently, I use QtCreator for debugging up until the point where it is unable to inspect structures (which it randomly decides to do, not sure when or why), and then I switch to GDB for those circumstances.

- Casey

Ah okay. I thought maybe you hadn't seen DDD yet because it's somewhat obscure.

I also tried CLion, a new commercial IDE from JetBrains, but I couldn't get it to easily debug an external binary, since it insists on using CMake. Apparently you can call your build script from CMake, but that sounds pretty icky.

The state of these tools is quite embarrassing, IMHO.

The last time I checked, DDD was terrible at peering inside structures, and especially STL containers (not that this is relevant to HH).

The best one I've seen so far is the Eclipse layer on top of gdb/lldb.

@Pseudonym73 terrible in what way? I haven't run into any problems yet, but I've only been doing some really basic stuff. Far more annoying for me is that it constantly moves things around without me telling it to.

Terrible in the sense that large nested data structures were all on one line, making navigation impossible. I haven't looked at DDD in about two years, so things may have changed.

@Pseudonym73 Yeah, the layout algorithm is really bad. If someone fixed that and the other UI oddities (basically just make it more uniform with contemporary GUI applications), it would be perfect for my use case.

I guess I'll just ask here. Would it be worth it to learn using gdb from command line?

Yeah I guess so. There's not much to learn to get basic functionality out of it.

1. 1	gdb ./main

   to load a program

2. 1	break <file>:<line number>

   to set a break point.

3. 1

   run

   to run the program

4. 1

   s

   to step

5. 1

   n

   for next line (I think, it's been a while).

6. 1	show <variable>

   to show some var's value

There's always the command, too.

For everyday use though, I'd definitely recommend a front end.

cmuratori

Currently, I use QtCreator for debugging up until the point where it is unable to inspect structures (which it randomly decides to do, not sure when or why), and then I switch to GDB for those circumstances.

Did you try asking about the problem on Qt Creator mailing list and/or reporting a bug? The devs are pretty responsive in my experience.

Andrey, the maintainer of debugger front, fixed few things for me on request.

Of course, you know if the effort outweighs the benefit for you or not.

I was able to set up CLion to debug an external executable without much trouble. I've written about it here, but will paste it below too:

I believe CLion is intended to be used as a full IDE for building CMake based projects, but using CMake is not strictly required in order to use it as a debugger.

I was able to set up CLion to debug a non-CMake built executable like this:

Start CLion, Create a new project
Name it whatever you want and put it where ever you want. This is just a throwaway project to allow you to use CLion’s interface to debug an executable of your choosing, so doesn’t even have to live inside your project’s directory. In fact, unless you want a cmake file in your project’s directory, don’t put it in there.
Once in CLion, Run Menu > Edit Configurations. Click the “Build All” item on the left and hit the delete key. This step is not strictly necessary, but I find it makes things less confusing.
You should now have just one configuration in the list with the same name as your project. Make sure it’s selected.
On the right, select the Executable dropdown and choose Select Other. Set it to the debug build of your executable. Click Ok to close the dialog.
Run Menu > Debug ‘yourprojectname’ will now launch your executable under the CLion debugger.
Drag source files in or File > Open them and set breakpoints and it should work. Click on the Debugger tab at the bottom and there will be a callstack navigator as well as locals and watches, etc.
Like basically all current graphical linux debuggers, CLion is just a frontend for GDB .

My first impressions?

Updates to the watch window when stepping are quite slow. Every time you step, it seems to remove all the items in the watch list and (very) lazily re-add them instead of just updating the values in-place. It can take a full second or more to see an update.
There are emacs keybindings available in the settings, and a vim plugin. I tried the vim plugin and it seems decent enough for the basics.
I can’t find a CPU registers view of any kind, which sucks. Hopefully I’m just missing it.
No way to attach to an already running process yet
Ability to inspect structures seems decent

Oh wow, this is great!

I just tried it on osx for my game project (which does a similar shared lib reloading thing that casey does but on osx) and it worked great! I tried many times to get xcode to debug my game and it never worked out. This is the first usable graphical debugger that's worked and it's a welcome improvement over command line gdb, just used it to fix a nasty bug.

I agree it's missing some wanted features like disassembly viewing but right now I think this is probably the best alternative for osx/linux and what I'll be using for the time being.
After the free trial of clion ends your sessions are limited to 30mins which is probably long enough to debug little things and since I use emacs/command line for actual editing/compiling I don't even need the full version.

Yeah, CLion is probably the best bet right now.