Do you debug C++ code in Vim? How?

Question

The question is to all you people, who use Vim to develop C++ applications.

There was a period in my life, which can be described as 'I hate Vim!!!'..'Vim is nice!'

However, having grown up mostly on Microsoft development IDEs, I've got used to those F5-F11 shortcuts when debugging code, watch window, call stack and the main code - all visible without need to type any GDB commands.

So, here is the question:

Do you use Vim as well for debugging? Or do you switch to some IDE for this purpose? Which one?

For those who use Vim to debug code: are there plugins to set breakpoints in editor, highlight the line we're currently debugging, auto-navigation during step, step into, step out?

Please, don't tell me you use GDB as command line, see only one line which is debugged, etc.

I'm sure you can still find people developing and debugging with "ed". — Déjà vu, Aug 21 '10 at 06:27
Are you stuck on Vim or willing to look at other editors like Emacs which has great gdb integration built-in? Is the main issue with gdb the single line output by default or to avoid typing l(ist) constantly which gdb -tui helps with? — jla, Feb 18 '15 at 17:38
Superset: https://stackoverflow.com/questions/4237817/configuring-vim-for-c But I urge you to use Eclipse with Vim keybindinds for the class awareness. — Ciro Santilli OurBigBook.com, Oct 28 '19 at 08:40
Specific question on Vi.SE (only concern gdb, but there's a lldb reference there): [external command - How can I integrate gdb with Vim? - Vi and Vim Stack Exchange](https://vi.stackexchange.com/questions/2046/how-can-i-integrate-gdb-with-vim) — user202729, Jan 21 '22 at 03:31

score 80 · Accepted Answer · answered Aug 21 '10 at 23:51

80

In contrast with the other answers, there are at least three options that do just what you require: clewn, pyclewn and vimgdb.

All three projects are related. vimgdb is a patch against Vim and requires Vim to be recompiled. clewn is a standalone program that communicates with Vim through the Netbeans socket interface. This requires Vim to be built with the +netbeans option (this is the case in recent Linux distributions so it shouldn't be a problem).

To quote from the clewn's website:

Clewn implements full gdb support in the vim editor: breakpoints, watch variables, gdb command completion, assembly windows, etc.

I think you should definitely give it a go.

The homepage of the pyclewn website shows a comparison between the three projects.

A few months ago I tried pyclewn. It was a bit difficult to set up, but it looks well though out and promising. I just did some tests and you could set bookmarks, etc., the usual stuff you would expect from a graphical debugger. I ended up not using it for contingent reasons but I am keen to give it another try.

answered Aug 21 '10 at 23:51

UncleZeiv

18,272
7
49
77

6

Conque GDB is a nice alternative. Easy to install, simple and very powerfull. – Druesukker May 09 '13 at 10:58
@UncleZeiv vimgdb is outdated. I expressed the need for an update here: https://github.com/larrupingpig/vimgdb-for-vim7.4/issues/4 – hlin117 Jan 13 '15 at 03:54
@Druesukker, your reply deserves a formal answer! – solotim Nov 17 '17 at 04:34
@UncleZeiv Your link to vimgdb doesn’t. It should go to https://github.com/larrupingpig/vimgdb-for-vim7.4, I guess – mcepl Nov 23 '17 at 15:53
2

Just to add a vim "like" debugger based off GDB - https://cgdb.github.io/ – mirageglobe Apr 03 '19 at 08:00

dannyadam · Answer 2 · 2019-05-13T13:31:40.873

Vim added a built-in debugger officially in version 8.1, released in May 2018. The feature had been present in some of the version 8.0 releases as well, as early as August 2017.

The following vim commands load the plugin and start the debugger.

:packadd termdebug
:Termdebug

The latter command takes a program as an optional argument, or alternatively a program can be loaded from the gdb window with the file command.

With the plugin loaded, gdb can be used interactively in the corresponding window. For example, breakpoints can be set, code can be stepped through, and variables can be inspected.

Vim commands can be issued for interacting with gdb. Some relevant commands include :Step, :Over, :Finish, :Continue, :Stop, :Break, :Clear, and :Evaluate.

Additionally, there are clickable buttons at the top of the editor window for interacting with gdb.

The editor window is updated to reflect the state of debugging. Breakpoints are indicated with >> and the current line is highlighted.

The built-in help page includes thorough documentation.

:help terminal-debug

I recently wrote a blog post that walks through an example session.

https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

For newer macOS versions the gdb doesn't work at all :( It just stuck after run. But this is not just vim but also in gdb cli. https://stackoverflow.com/questions/62474236/gdb-hangs-after-calling-run-on-mac-os-catalina — Dirk N., Jun 30 '21 at 22:05

score 26 · Answer 3 · answered Mar 13 '20 at 17:20

Update 2020: There is a new plugin vimspector using the Debug Adapter Protocol

Install the plugin https://github.com/puremourning/vimspector#installation
Configure (write .vimspector.json)
Compile with debug symbol g++ cpp.cpp -ggdb -o cpp
Press F4 to start debug

Note my .vimspector.json in my home directory (so work in any subdir)

{
"configurations": {
  "Python - Launch": {
    "adapter": "vscode-python",
    "configuration": {
      "name": "Python: Launch current file",
      "type": "python",
      "request": "launch",
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "Perl - Launch": {
    "adapter": "vscode-perl-debug",
    "configuration": {
      "name": "Perl: Launch current file",
      "type": "perl",
      "request": "launch",
      "exec": "/usr/bin/env perl",
      "execArgs": [],
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "sessions": "single",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "C - Launch": {
    "adapter": "vscode-cpptools",
    "configuration": {
      "name": "Cpp: Launch current file",
      "type": "cppdbg",
      "request": "launch",
      "externalConsole": true,
      "logging": {
        "engineLogging": true
      },
      "stopOnEntry": true,
      "stopAtEntry": true,
      "debugOptions": [],
      "MIMode": "gdb",
      "cwd": "${cwd}",
      "program": "${fileDirname}/${fileBasenameNoExtension}"
    }
  },
  "Java - Launch": {
    "adapter": "vscode-java",
    "configuration": {
      "name": "Java: Launch current file",
      "request": "launch",
      "mainClass": "com.vimspector.test.TestApplication",
      "sourcePaths": [ "${workspaceRoot}/src/main/java" ],
      "classPaths": [ "${workspaceRoot}/target/classes" ],
      "args": "hello world!",
      "stopOnEntry": true,
      "console": "integratedTerminal"
    }
  }
} }

Compile with debug symbol `g++ cpp.cpp -ggdb -o cpp` --> directly in Vim for any C++ [filename](https://vim.fandom.com/wiki/Get_the_name_of_the_current_file) `:!g++ % -ggdb -o $(basename -s .cpp %)`. Or for `C` use `-s .c`. — Xopi García, Jan 24 '21 at 14:13
"Press `F4` to start debug". I guess you have in `.vimrc` something like `nnoremap :call vimspector#Launch()`, don't you? Or is that mapping installed with `vimspector`? — Xopi García, Jan 24 '21 at 14:15

score 16 · Answer 4 · edited Jun 14 '17 at 23:21

16

Vim is a nice editor, but to do debugging I use a debugger (like GDB).

But you don't have to use GDB in text mode; you can use a graphical frontend like KDbg, DDD or Insight.

There are ways of getting GDB into Vim (but then you do get text based debugging).

edited Jun 14 '17 at 23:21

Peter Mortensen

30,738
21
105
131

answered Aug 21 '10 at 06:37

Johan

20,067
28
92
110

Ciro Santilli OurBigBook.com · Answer 5 · 2020-07-01T15:50:30.677

GDB edit command

Opens an editor on the current line using the command:

$EDITOR +<current-line> <current-file>

The default editor is ex, but vim also understands the +<current-line> format.

When you quit the editor, you get back into gdb.

This allows you to browse the source freely and is specially powerfull if you have ctags integration.

This is a poor-man's built-in one way gdb to vim integration: the main missing thing is setting breakpoints from Vim.

edit and center

edit does not center Vim by default around the source, so I've created a Python script that does it: How to open the current file at the current line in a text editor from GDB?

Breakpoint command to clipboard helper

This vim command copies a breakpoint specifier of type:

b <file-path>:<line-number>

to the clipboard:

command! Xg :let @+ = 'b ' . expand('%:p') . ':' . line('.')

Then you can just paste that into gdb.

This is a poor man's vim to gdb integration to ease setting breakpoints.

GDB Dashboard

https://github.com/cyrus-and/gdb-dashboard

This has nothing to do with Vim, but it is a lightweight solution that achieves a lot and might suit other Vimmers out there.

Others have mentioned GDB TUI, but I found it too broken and not powerful enough to be bearable.

So I moved instead to Python API based solutions such as GDB Dashboard.

I have described used and rationale in more detail at: gdb split view with code

Here is a screenshot of what it gives you:

See also: https://vi.stackexchange.com/questions/2046/how-can-i-integrate-gdb-with-vim

Give up and use a real IDE

With all that said, this is the best solution for most people, including myself. Most people will just gain tons of time if they are able to jump around definitions in a C++ class aware manner without selecting and installing several different plugins themselves, and that includes while step debugging stuff. As of 2020 the least worst one for me was Eclipse: https://www.slant.co/topics/1411/~best-ides-for-c-on-linux

I would gladly upvote this if not the last paragraph about the "real IDE" (more so mentioning "eclipse" in that context). — Slava, Mar 16 '21 at 12:15
@Slava one day you shall see the Light, Slava, and be saved as I have XDXDXD — Ciro Santilli OurBigBook.com, Mar 16 '21 at 12:24

score 4 · Answer 6 · answered Aug 22 '10 at 00:31

4

Using a source level debugger is only one of many ways to diagnose faulty program behavior, and I rarely find myself launching one -- despite the fact that it is very easy to do.

So for me, there is simply no inherent advantage to using a text editor that happens to also be a debugger. Instead, I use the text editor that I prefer -- independent of what debugger I choose to use. At the moment, I mostly use gedit and kdbg for these purposes, but these choices evolve independently over time.

answered Aug 22 '10 at 00:31

Brent Bradburn

51,587
17
154
173

1

Unless youre developing remote on a kde/gnome-free development host. – user826955 Oct 14 '15 at 06:06
What are these other ways that you use? – midrare Jan 25 '23 at 23:04
@sorbet, More apropos now than it was then: ["The most effective debugging tool is still careful thought, coupled with judiciously placed print statements."](https://stackoverflow.com/a/238686/86967) – Brent Bradburn Jan 26 '23 at 01:03

score 1 · Answer 7 · answered Aug 21 '10 at 06:32

Having just recently worked on an application for a long time that required a bunch of stuff to be in place on the box it was running (appliance set up), I wrote code in vim, had scripts which automated building, pushing it to a server, which had a script there to notice the sentinel file pushed along with the binaries. This would then restart the appropriate services on the box, and in another ssh window I had a tail -f running on my log file.

Long story short, I didn't use a debugger at all. If I had something die unexpectedly, I'd just bump up logging levels, redo it, and see what was the last thing logged before it died, then analyze that and fix the issue.

The nice thing was that when something had problems in a customer environment, I'd just ask for a Debug-level log and could identify the issue without even requiring access to their server.

... but yes, there were times when it would have been nice to have a debugger.

score 1 · Answer 8 · answered Apr 03 '19 at 08:32

Just to add to above :

IMO vim tends to be quite a light editor and debugging tends to add to the weight. There are ways to do it i.e. using vim7.4+ with

:terminal

and running one of the following commandline (curses) debuggers. A few are used by default for IDEs that you never knew. i.e. lldb = xcode.

(c/c++/objective c) gdb (gnu debugger) - https://www.gnu.org/software/gdb/
(c/c++/objective c/python etc) remake - http://bashdb.sourceforge.net/remake/
(java) oracle java debugger - https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html
(c/c++/objective c) lldb - https://lldb.llvm.org/

obviously there are more cli based ones; @all feel free to suggest and add to list. thanks!

score 0 · Answer 9 · answered Aug 17 '20 at 14:46

The answers for the vim editor are all excellent. The ubiquity of vim makes it a good choice to learn. If you're set on staying close to VS try geany. It'll provide similar F5-F11 encodings. You can fine tune it to be as close as you wish. It also has a configurable watch window and terminal output. As with all editors, there is a learning curve. Especially when dealing with plugins/add-ons. Also, it's possible to assign the functions you desire to the keys you choose in vim/gvim, emacs, geany.

Do you debug C++ code in Vim? How?

9 Answers9

Linked