Yes! Assuming you run it with --tui, otherwise you'll hate yourself forever.

It may seem to have some mental overhead at first because you have to type commands, but it becomes second nature after a while. IMHO, it has far less overhead than debuggers where you have to click everywhere. There's a reason why people don't really bother writing pretty frontends for it.

If you use an IDE for Linux development, its debugger actually talks to GDB behind the scene. You can ditch the middle man without trouble.

The only thing that DDD really excels at (when it doesn't crash because, uh, long story short, Motif) and you can't get straight from GDB is visual representation of linked structures.

In my experience, the cgdb [1] wrapper makes gdb a viable option, by providing what I think is the sorely missing piece in vanilla gdb: a window continuously showing the code context.

It also uses vim-like bindings for going into "insert" mode ("i"), versus escaping out into code context navigation mode ("ESC").

I made a short 4 minute tutorial on how to use gdb/cgdb for debugging Golang, here:

https://www.youtube.com/watch?v=OKLR6rrsBmI

[1] https://cgdb.github.io/

There is also gdb's built in tui mode. You can activate it with gdb -tui or keyboard shortcut C-x C-a.

Thank you! Thus is exactly what I've been looking for.

God God, yes. Five minutes is enough to learn how to get it going, add breakpoints, see the stack and interrogate variables. On a good day, you can fix a segFault faster than it would actually take you to spin up a visual debugger in an IDE or whatever.

Sure, it's not the right tool for every job, but as a simple, easy to use, ubiquitous and quick debugger, you'd do yourself a favour spending the five minutes learning how to start using it.

Use DDD instead.

https://www.gnu.org/software/ddd/

Or Nemiver:

https://en.wikipedia.org/wiki/Nemiver

Or KDbg for us KDE users:

http://www.kdbg.org/

I think the best debugging option on the market is the Emacs gdb integration. It truly is quite remarkable.

I agree. I was using that in 2000 to debug C++ code and it was very good.

As others mentions the tui mode is very nice. Important thing to learn about using gdb is to write your .gdbinit file before running gdb. Write the commands like 'file <your-exe>', 'break <your-src>:<line-number>', 'catch throw', etc. and then run gdb. What I usually do when I need to set a breakpoint in a new place is I quit gdb, edit .gdbinit and start again. This way all breakpoints are always saved. gdb is better then most people think.

Have you tried to use GDB from emacs? It's like Visual Studio

Ha! It's nothing like Visual Studio. GIMP is closer to Photoshop than Emacs + GUD/GDB is to Visual Studio.

However, I do use Emacs with GUD and it works okay. If you are addicted to VI-style editing (like myself), you can use viper.

You'll want to add some keybinding to your .emacs. The following are the VS6 bindings I use:

;; Add VisualStudio-style debugging keys

;; Add convenient "until" command to gdb mode (swiped off the web)

(add-hook `gdb-mode-hook

        (lambda ()

         (gud-def gud-until "until %f:%l" "C-u" "Execute until current line.")))

;; Add a "jump" command (supposed to have been included in gud.el)

(add-hook `gdb-mode-hook

        (lambda ()

         (gud-def gud-jump "tbreak %f:%l\njump %f:%l" "\C-j" "Relocate next instruction to line at point in source buffer.")))

(global-set-key [f9] 'gud-break)

(global-set-key [f11] 'gud-step)

(global-set-key [f10] 'gud-next)

(global-set-key [f5] 'gud-cont)

(global-set-key [\S-f11] 'gud-finish)

(global-set-key [\C-f10] 'gud-until)

(global-set-key [\C-\S-f10] 'gud-jump) ; Equivalent to VC's Set Next Statement

These days evil is the goto vim-keybinding package - viper is unmaintained IIRC and hasn't been for some time, and evil works tremendously well.

I launch gdb in "batch mode" from a shell file with "gdb --batch -x command.txt" to get the callstack under exception.

https://github.com/vmorgulys/sandbox/blob/master/stackcity/t...

    set pagination off
    catch throw
    run
    bt 50
    quit

If you have a visual debugger, maybe not.

But if you have complex bugs to track, the integration of Python in GDB alone is worth the hassle, I think.

Learn cgdb instead.