OK, for someone who's written a lot of C++ in Visual Studio but is now developing on Linux: is it worth learning GDB? It seems like it'll always have some mental overhead compared to a visual debugger, but on the other hand I was never crazy about using an IDE...

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.

somewhat offtopic, but has anyone used lldb lately, when I last used it I found it much worse than gdb but I expect it will at somepoint surpass gdb (like the rest of LLVM has done to GNU (if you're on x86_64))

At Ticketmaster, I learned the first thing you write when you start on bare metal is a debugger. I worked on VAX, 68000 and 8051 bare metal.

The difference between an amateur operating system project and a professional one is writing a compiler.

Forth and HolyC have both.

You're replying to the guy that wrote HolyC.

Yes, I know :-)

You still work for TicketMaster or was it long ago ?

Take a look at Terry's project if you don't know it yet:

http://www.templeos.org/

I think most of us know who Terry is, but it's the first time I see him mentioning TicketMaster. That said, the website does mention 1990 for TM, so I got part of my question. Thanks.

No offsense :-)

Just read about TicketMaster on his site.

How do I use this on OS X 10.11?

You can build the gdb executable manually on OS X 10.11.

First, run this if you haven't already installed the Command Line Tools for Xcode:

  xcode-select --install

Then run these commands:

  curl -o gdb-7.11.tar.xz https://ftp.gnu.org/gnu/gdb/gdb-7.11.tar.xz
  tar zxf gdb-7.11.tar.xz
  cd gdb-7.11
  ./configure
  make
  make install

This should place the executable at /usr/local/bin/gdb. The final step is to codesign it. Instructions: http://sourceware.org/gdb/wiki/BuildingOnDarwin

`tar xfJ gdb-7.11.tar.xz` for .xz files

Good point. GNU tar requires using the correct option, -J, when extracting an xz-compressed tarball.

But OS X tar is bsdtar, which ignores -z and -J when extracting because it automatically recognizes compression and does the right thing. So it turns out both our suggestions happen to work on OS X.

nonsense, gnu tar unpacks anything with tar xf <file> just fine.

Oh, good point, I wasn't aware that GNU tar also supported automatic compression recognition. I should have tested it. Thanks!

More on code signing gdb here: http://www.getlazarus.org/setup/macintosh/

A related question is: does it make sense to use this on OS X? lldb is certainly better integrated with the system, does gdb really have benefits that make up for that?

I dont develop much on osx anymore, but I suspect this will be available in homebrew at some point.

brew install gdb