Live data from Hacker News

GDB tricks

blogs.oracle.com

11–20 of 35 posts

Re: GDB tricks

#11
post #3

This lack the best option: ctrl-x a Don't bother having a external GUI, just use the built-in Ncruses one.

The QtCreator debugger is actually pretty decent, and I prefer it to gdb -tui and cgdb. The debugger in the early-access version of CLion looks promising, but it lacks essential features like a disassembly view and a memory view, and sadly they aren't mentioned on the current 1.0 roadmap.

Emacs's gdb-mi mode has the potential to be the best out there. Unfortunately it has some critical weaknesses in its current form. The biggest is that it uses the awful speedbar extension for its watch window. And gdb-mode's local variables window is useless as it won't allow you to inspect any aggregate types like structs and arrays, so you're forced to use the aforementioned awful speedbar-based watch window just to inspect local variables. I'm hoping to fix this or rewrite it entirely when I have time.

Re: GDB tricks

#12
The one feature that has been present in almost all the other debuggers I've used, and is apparently missing from GDB, is a standard hexdump - addresses, byte values, and ASCII. It's possible to emulate this with a bunch of extra steps, but the omission of such a simple feature is surprising. All the times I've had to use GDB the feeling I get from it is "makes very difficult things easier, but makes very easy things more difficult."

Re: GDB tricks

#14

The one feature that has been present in almost all the other debuggers I've used, and is apparently missing from GDB, is a standard hexdump - addresses, byte values, and ASCII. It's possible to emulate this with a bunch of extra steps, but the omission of such a simple feature is surprising. All the times I've had to use GDB the feeling I get from it is "makes very difficult things easier, but makes very easy things…

It requires a little getting used to, but quite powerful:

http://www.delorie.com/gnu/docs/gdb/gdb_56.html

Re: GDB tricks

#15

Isn't lldb better option now? Commands are more structured. FWIW, gdb on OSX is a pain to setup, and attaching processes is broken.

On osx, perhaps. On Linux it's still a little rough. Or was last time I tried to use it. That said, I do look forward to using it more. But most importantly, I look forward to the tooling that can be built around it, since it's much easier to treat it as a library than gdb.

Re: GDB tricks

#16
post #3

This lack the best option: ctrl-x a Don't bother having a external GUI, just use the built-in Ncruses one.

The QtCreator debugger is actually pretty decent, and I prefer it to gdb -tui and cgdb. The debugger in the early-access version of CLion looks promising, but it lacks essential features like a disassembly view and a memory view, and sadly they aren't mentioned on the current 1.0 roadmap. Emacs's gdb-mi mode has the potential to be the best out there. Unfortunately it has some critical weaknesses in its current form.…

Rocky Bernstein's GUD rewrite may be of interest: https://github.com/rocky/emacs-dbgr

I don't think it has a watch window yet, or a disassembly or memory view. It has a cleaner architecture than the original GUD though, which might make it more pleasant to do major development on. It supports more backend debuggers, multiple concurrent sessions and attaching to a debugger session in an existing Comint buffer (presumably that means it supports attaching to existing processes as well; don't know if the original GUD gdb mode does that).

It does have the nifty idea of a minor-mode that is activated in source buffers that makes the buffer read-only and maps debugger commands to single keystrokes, eg. n for next, s for step, etc. ('Insert' toggles it off in case you actually want to do some editing).

The gdb support seems currently a bit basic. For example if you highlight an expression and press 'e' it sends "eval " to gdb when of course it should be "print". (It sounds like the main dev effort has been on the Ruby debugger so far). I get the feeling it might just need a little TLC to make it great.

For now, I agree the speedbar, and the experience of a watch window in it, is awful. Having seen how powerful gdb's print command is (doing very well with aggregate types, and now with the latest gdb you can switch on some Python-based pretty printing for it as well), as a temporary personal init-file hack I brought the single-key mode to the original GUD making sure to include 'p' to 'print' and capital 'P' to 'print*' the currently highlighted text, or the current word if nothing is highlighted. If the gdb buffer isn't visible, it prints to the minibuffer, else if the gdb buffer is visible, it goes there, and then I can move the cursor around and use seperate Emacs folding commands to collapse and expand the braces. It's still a bit raw but I'm so pleased with it that I already don't miss Visual Studio (the supposed gold standard for user-friendly debugging, yet even in the latest version I find it distressingly weak at inspecting common STL types).

I might try and contribute to Rocky's mode myself when I have the time.

Re: GDB tricks

#17

Earlier quoted context omitted.

The QtCreator debugger is actually pretty decent, and I prefer it to gdb -tui and cgdb. The debugger in the early-access version of CLion looks promising, but it lacks essential features like a disassembly view and a memory view, and sadly they aren't mentioned on the current 1.0 roadmap. Emacs's gdb-mi mode has the potential to be the best out there. Unfortunately it has some critical weaknesses in its current form.…

Rocky Bernstein's GUD rewrite may be of interest: https://github.com/rocky/emacs-dbgr I don't think it has a watch window yet, or a disassembly or memory view. It has a cleaner architecture than the original GUD though, which might make it more pleasant to do major development on. It supports more backend debuggers, multiple concurrent sessions and attaching to a debugger session in an existing Comint buffer (presuma…

Thanks, I didn't know about the GUD rewrite.

After I wrote my post above, I started work on a GDB mode from scratch. So far, I have the process management and a PEG-based parser (peg.el is great) for MI output working. I'm not sure if you've looked at gdb-mi.el's code, but it was written by a GSoC student and does vile shit like munging MI output with regular expressions so it can be fed to json.el and parsed as valid JSON. In similar lazy fashion, it uses GUD just for process management. I don't feel there's anything worth salvaging or building on in there.

Re: GDB tricks

#18
post #7

These are all useful, and I would even say fundamental, commands. But, as such, these are also very basic commands, not tricks. If you're looking for something more advanced, you'll be disappointed. I strongly suggest to anyone using gdb to just read the manual [0]. Or at least skim it quickly and find a dozen of such useful "tricks" in as many minutes. The time gained in debugging later is well worth knowing and mas…

I found constructing small problems and solving them with GDB when not under pressure greatly expanded my working knowledge. Trying to learn GDB while attempting to solve a time critical production bug is not possible for me.

Re: GDB tricks

#19

Isn't lldb better option now? Commands are more structured. FWIW, gdb on OSX is a pain to setup, and attaching processes is broken.

Copying `/usr/bin/gdb` and `/usr/libexec/gdb/gdb-i386-apple-darwin` from an OSX Lion installation is one way to get a functional gdb on Mountain Lion or Yosemite.

Re: GDB tricks

#20
post #9

> By Ksplice Post Importer on Jan 24, 2011 Heh. When interning at Ksplice/Oracle in 2011, I was tasked to import all of the blog posts from the old Ksplice Wordpress blog into Oracle's system. By hand, because they didn't want to turn on the Apache Roller API, or something. I couldn't set a custom author for each post, so instead I changed my name to "Importer, Ksplice Post".

I would have left my internship if I was tasked with that.
Post reply on HN