7 ms·

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 menta

by blt 11y ago

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...

EliRivers 11y ago
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.
cheez 11y ago
Learn cgdb instead.
pjmlp 11y ago
Use DDD instead. https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
- vmorgulis 11y ago
  Or Nemiver: https://en.wikipedia.org/wiki/Nemiver https://en.wikipedia.org/wiki/Nemiver
  - bubuga 11y ago
    Or KDbg for us KDE users: http://www.kdbg.org/ http://www.kdbg.org/
Arkanosis 11y ago
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.
deleted 11y ago
[deleted]
samuell 11y ago
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 https://www.youtube.com/watch?v=OKLR6rrsBmI [1] https://cgdb.github.io/ https://cgdb.github.io/
- tbirdz 11y ago
  There is also gdb's built in tui mode. You can activate it with gdb -tui or keyboard shortcut C-x C-a.
- chris_wot 11y ago
  Thank you! Thus is exactly what I've been looking for.
notalaser 11y ago
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.
vmorgulis 11y ago
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/tool/gdb/command.txt https://github.com/vmorgulys/sandbox/blob/master/stackcity/t... set pagination off catch throw run bt 50 quit
nodivbyzero 11y ago
Have you tried to use GDB from emacs? It's like Visual Studio
- prewett 11y ago
  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
  - benaiah 11y ago
    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.
webkike 11y ago
I think the best debugging option on the market is the Emacs gdb integration. It truly is quite remarkable.
- abawany 11y ago
  I agree. I was using that in 2000 to debug C++ code and it was very good.
piokuc 11y ago
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.

by blt 11y ago

EliRivers 11y ago

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.

cheez 11y ago

Learn cgdb instead.

pjmlp 11y ago

Use DDD instead. https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/

vmorgulis 11y ago
Or Nemiver: https://en.wikipedia.org/wiki/Nemiver https://en.wikipedia.org/wiki/Nemiver
- bubuga 11y ago
  Or KDbg for us KDE users: http://www.kdbg.org/ http://www.kdbg.org/

Arkanosis 11y ago

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.

deleted 11y ago

[deleted]

samuell 11y ago

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 https://www.youtube.com/watch?v=OKLR6rrsBmI [1] https://cgdb.github.io/ https://cgdb.github.io/

tbirdz 11y ago
There is also gdb's built in tui mode. You can activate it with gdb -tui or keyboard shortcut C-x C-a.
chris_wot 11y ago
Thank you! Thus is exactly what I've been looking for.

notalaser 11y ago

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.

vmorgulis 11y ago

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/tool/gdb/command.txt https://github.com/vmorgulys/sandbox/blob/master/stackcity/t... set pagination off catch throw run bt 50 quit

nodivbyzero 11y ago

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

prewett 11y ago
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
- benaiah 11y ago
  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.

webkike 11y ago

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

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

piokuc 11y ago

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.