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, 2015 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, 2018 at 1:05
  • 1
    To all readers of this (six year old) question : Vim 8 now comes with its own gdb plugin. Check out @thakis answer or sort answers by "Active"
    – cassepipe
    Sep 21, 2021 at 13:34

5 Answers 5


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, 2016 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, 2016 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, 2016 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, 2016 at 11:28
  • Some note on the plugin • seems to be unmaintained (there are 3 pull requests there to fix the collections.abc warning) • uses Python 2 by default, conflict if there's other plugin that uses Python 3 • doesn't use vim's terminal facility (because the plugin was written before :term is available in vim), instead writes its own, user need to define key map manually separately from tmap. // See also terminal - Is there an upgraded version of the Conque plugin? - Vi and Vim Stack Exchange
    – user202729
    Jan 21, 2022 at 10:05

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, 2015 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... Feb 20, 2015 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? Feb 20, 2015 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. Feb 20, 2015 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. Feb 21, 2015 at 0:00

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

  • Also (not really vim's bug, just note that) if frame.select() Python API is used to switch frame, vim will not highlight the current line, even if the user call frame <current frame number> afterwards, because the thread-selected message is not sent to gdb.
    – user202729
    Jan 21, 2022 at 14:20
  • This plugin intentionally separate the inferior terminal and the gdb terminal though. Might be undesirable depends on person. (although can probably be workaround by closing the buffer with that name and invoke tty on gdb)
    – user202729
    Jan 21, 2022 at 14:27

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:



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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