Instead of gdbtui or ctrl+x under gdb which shows source code on top of the screen I would like to see this in my Vim editor that would jump between tabs, and buffers accordingly.

How can I do this?

  • Just for reference I found lldb plugin @ github.com/gilligan/vim-lldb and screenshots look promising. – name Jul 3 '15 at 7:43
  • BTW, anyone knows something about windbg? Vim integration could have been a good idea. Although, actually I think this about almost any software there is. – eyal karni Dec 30 '18 at 1:05

Among all the plugins I have tried, I found ConqueGDB to be the best approach. ConqueGDB uses Conque Shell to embed an interactive shell inside vim, that is used by GDB.

The workflow with ConqueGDB consists not entering GDB commands on the GDB terminal, you use shortcuts on the vim source code. But you can continue using the GDB prompt if you want, for more advanced commands, or scroll to see the whole debug session.

Some ConqueGDB default mappings, for example:

  • leaderr : run
  • leaderc : continue
  • leaders : step
  • leaderp : print variable under cursor

Notice how the vim cursor line has been used to issue a GDB 'print row', the current execution of code is in another line (14) and there's a breakpoint on line 10.

vim with CongueGDB

To install with Vundle for example:

Plugin 'vim-scripts/Conque-GDB'

I use these plugin options:

let g:ConqueTerm_Color = 2         " 1: strip color after 200 lines, 2: always with color
let g:ConqueTerm_CloseOnEnd = 1    " close conque when program ends running
let g:ConqueTerm_StartMessages = 0 " display warning messages if conqueTerm is configured incorrectly  
  • what does leader mean? – In78 Mar 30 '16 at 22:13
  • @In78 It means the <kbd>\</kbd> key on most computers. For example <leader>r means <kbd>\</kbd>+<kbd>r</kbd> on my computers. Vim manual has an entry for it: :help leader – Parsa Jun 10 '16 at 0:55
  • Not to forget this ConqueGDB default mapping: <Leader>b. It sets a breakpoint at the cursor position. However, it is NOT a toggle, so you cannot use it to remove it again. Rather, you will have to write 'clear' on the GDB prompt. – serup Sep 29 '16 at 8:58
  • I have tried using this ConqueGdb and in order to get it to work I first have specify executable file - and sometimes it fails with setting brakepoints - I have to focus the gdb window and press I for insert, before the breakpoint will appear - is this normal for ConqueGdb? – serup Nov 18 '16 at 11:28

You have several plugins that integrates gdb.

  • We used to have pyclewn. The project has been discontinued after version 2.3. The last commit has been made in 2016. For the curious ones there is still a mirror on github where its author has archived his work. Note: pyclewn used to be the last stage step in the evolution of the other Xavier Degaye's *clewn projects.
  • vim-debugger, that integrates several other debuggers
  • notEvil's vim-debug, which acts as as "convenience layer for pyclewn to overcome some drawbacks"

And there is also a plugin that integrates lldb (from LLVM project)

It seems that Bram is currently (september 2017) working on the integration of gdb from within vim thanks to the new :terminal feature. To use it, we need to load termdebug packet (with :packadd termdebug), then we'll be able to start a gdb console in a vim window with :TermDebug (+options). IMO, we can consider it to be the future of GDB integration under Vim.

  • 4
    Good - can you give a short overview of each of these plugins? – muru Feb 20 '15 at 10:49
  • 1
    ?? Links are to the plugins official pages. Yes they can change if the plugins disappear or if they are moved elsewhere. In that case, I'll update the message in the first case as I did before on SO. And in the second case, it would mean that part of any message that details what the plugin does would become deprecated. Worse case scenario: detailing what the plugin really do will become obsolete while their respective author work on them, add features, and so on. Any way. I'll add a brief description of them next week... – Luc Hermitte Feb 20 '15 at 17:24
  • 2
    @LucHermitte The post came up in the review queue; I didn't add the exact text of this message myself, the system did that for me. In any case, link only answers are considered "bad" on SO and most, if not all, SE sites. Not just because they may go out of date, but also because they don't really explain things; almost any question could be "answered" by linking to the right documentation page(s), hell, you could even link to the source code, but does that really explain something? Is that really useful? Does that really contribute to someone's understanding of Vim? – Martin Tournoij Feb 20 '15 at 19:25
  • 1
    "I didn't add the exact text of this message myself, the system did that for me". OK. That explains the message, which I found quite odd. Regarding links. I understand SO/SE policy about RTFM/SFTW. Unlike other forums, recurring/duplicate questions are closed when detected, and SO/SE tends more toward a wiki approach. – Luc Hermitte Feb 20 '15 at 23:54
  • 3
    Regarding where to find plugins. I could duplicate their documentation. But it won't help much. Moreover, it's almost impossible to keep the answer up to date as the plugins evolve. Adding a not-up-to-date short summary of the features is possible, and I'll see to it. In any case, their official page is the entry point. Regarding plugins, this is the first important information. Indeed, a nice presentation could appeals to us... Until we find out the plugin cannot work in our particular case -- which happens often with FSOSS. This is where a list of available solutions is also interesting. – Luc Hermitte Feb 21 '15 at 0:00

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: https://stackoverflow.com/questions/43557405/how-to-open-the-current-file-at-the-current-line-in-a-text-editor-from-gdb/43557406#43557406

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.

See also: https://stackoverflow.com/questions/3536600/do-you-debug-c-code-in-vim-how


Although not technically vim. cgdb is a curses version of gdb with vim-like keybindings. It's been my goto debugger for years:


  • Yup that's what I was looking for... thanks alot – Mahmoud Salah Apr 3 at 1:46

Vim 8.1 adds debugger integration, see :help terminal-debug. The summary is that you run

:packadd termdebug
:Termdebug myprogram

And then you can set breakpads either in the gdb buffer using b myfunc, or in the vim window with :Break, or by right-clicking a line and picking "Set breakpoint". Similarly, there are 3 methods for running the program, stepping, etc. You can hit K in the vim source buffer to see the value of the expression under the cursor in the status bar (:messages gives you a history as usual).

https://www.dannyadam.com/blog/2019/05/debugging-in-vim/ has a full worked example.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.