Learning the GDB commands is on my bucket-list, but in the meantime is there a graphical debugger for *nix platforms that accepts Windbg commands, and has similar functionality? For example, the ability to bring out multiple editable memory windows, automatically disassemble around an area while stepping, set disassembly flavor, and have a window with registers that have editable values?


19 Answers 19


I started my own gdb frontend called gdbgui which is a server (in python) that lets you access a full-featured frontend in your browser.

gdbgui screenshot


pip install gdbgui --upgrade

or download at gdbgui.com

Works on all platforms (Linux, macOS, and Windows) and browsers with JavaScript.


Just type


in your terminal, and your browser will open a new tab.


  • set/remove breakpoints
  • view sourcecode, with optional inline machine code
  • select current frame in stack
  • step through source code or machine code
  • create/explore variables
  • view/select threads
  • explore memory
  • view registers
  • full gdb terminal functionality so you can send traditional gdb commands, and view gdb/inferior program output
  • layout inspired by the amazing Chrome debugger
  • compatible with Mozilla's RR, for reverse debugging
  • This is some good work, truly. The design gets to the core of the average use-case. I like it. It also supports remote debugging (or, rather, it supports using the target remote host:port gdb command. Nicely done. Perhaps adding the ability to connect to a remote host in the menu would be a nice add-on. Would it be possible to scale down the 'register` size? All the information is available, but (at least on ARM) you can't see all registers at once, so you have to scroll.
    – sherrellbc
    Mar 7 '19 at 11:06
  • 5
    The comments in here are not for individual gdbgui support. Please open a new question on sx, or use the gdbgui support channels / bug tracker. Nov 21 '19 at 21:44
  • Can this report if a binary has all the buffer overflow protections?
    – ATL_DEV
    Sep 16 at 19:34

Although some people don't care for its interface, it's worth mentioning that GDB has its own built-in GUI as well (called TUI).

You can start GDB in GUI mode with the command: gdb -tui

A quick reference to TUI commands may be found here: http://beej.us/guide/bggdb/#qref


I've generally used Emacs GUD as a GDB frontend.

GDB support in Emacs

It isn't too hard to use, allows you to set breakpoints visually (or though the GDB window if you prefer).

It has multiple different views that you can access from a top-level GDB menu:

GUD Views

It also allows niceties like allowing you to inspect values by mousing over them:

Mouseover values

In order to use it, you first need to navigate to the folder of your binary with C-x C-f, then M-x gdb (That's "Alt + X", then typing "gdb"). After doing this, you can type a gdb command line, or just hit [Enter] to accept its default. From there, you just type "start" in the gdb window with any parameters you want to pass to the program you are debugging.

After that, you are pretty much golden, but with only one view. The menus along the top of the screen under "GUD" will let you open other relevant views for whatever you are trying to debug. (Frames are separate windows, and "Windows" are in-frame windows)

Usually by default, a breakpoint is set on program start, and you can then either navigate your code using the buttons at the top of the window, or if you have no code, you can customize your view to let you step through a disassembly of the binary you are looking at.

The buttons along the top of the window surrounded with "{}" are for code-level stepping, and the buttons with "<>" in their icon are for instruction-level debugging. So you will probably want to focus on the left if you are doing normal code debugging, and focus more on the right if you are getting into the real nitty-gritty.

Also, if you ever get lost, this icon:

GUD info

It is an entire book that can likely answer your questions. The only time it won't exist in Emacs is if you are on Debian (Ubuntu is fine) and installed Emacs from its repos. In which case you will need to install "emacs<vesrsion>-common-non-dfsg" to get the manuals. (With "<version>" being the non-decimal digits returned by M-x version in Emacs)

  • cant enable any panes to show locals or breakpoints using gud. What am is missing? Noting in the gud menu to suggest this is possible. the -mi interface shows them.
    – RichieHH
    Mar 11 at 23:51
  • 1
    @RichieHH oh! Those should be in Gud -> GDB-Windows in your menu-bar (If you don't have a menu-bar, F10 can get you into that)
    – Archenoth
    Mar 12 at 18:47

My opinion is a bit biased but, for debugging assembler, the best GDB 'frontend' out there is IDA (it supports communication with remote GDB targets). For source code debugging, though, I would recommend KDBG.

  • 5
    I would actually recommend using IDA's linux_server over remote GDB, it's more capable and faster (since it uses binary protocol and not text-based one).
    – Igor Skochinsky
    Apr 2 '13 at 4:11
  • 6
    Please justify your recommendation. The answers are written not just for the OP but for all the other people who may come across this in the future.
    – asheeshr
    May 9 '13 at 1:53
  • Basically because you have all the power of IDA (plugins, IDAPython scripting, known GUI, ...) and is not only a frontend for GDB. May 10 '13 at 6:37

Even at the risk of severe downvoting, I'd like to side with the plain old gdb prompt and recommend against a GUI frontend. I started out learning more advanced use of GDB by reading Art of Debugging some years ago. It describes GDB and DDD as well as Eclipse as frontends to GDB.

Admittedly most of the time I am using Vim as my IDE on the terminal and tmux (earlier screen with byobu). Therefore I am switching between panes in my terminal multiplexer to switch quickly between code and debugger. The GDB prompt - after some weeks of trying the TUI - has indeed everything I ever desired and you should keep in mind that you can attach multiple times to the same process (thereby having a look at memory the way you describe it).

It seems that all frontends are lagging behind a little - no surprise - and it makes more sense to come to terms with the GDB prompt and its niceties and oddities. Keep in mind that on a bare-metal setup it may be the only thing you have. Thus it makes sense to learn it even if you find a "decent" GUI by your own standards.

Newer versions of GDB will also support Python scripting and through that provide a very powerful set of tools to debug, even just from the command line.

If you absolutely insist on using a GUI frontend, I would also recommend IDA Pro for the simple reason that it gives you a single frontend for a variety of debuggers and you have to learn (or customize) its shortcuts only once. Disadvantages: price and flexibility when you don't have a license on a particular machine or no way to tunnel to a GDB server etc ...

I'm not aware of any frontend of GDB that accepts WinDbg commands. And I can only emphasize again: you will reap the fruit of the time invested in learning vanilla GDB anyway. Don't shy away from the effort. There are plenty of things in WinDbg which are specific to the way Windows works, the Windows kernel works and so on. GDB is much more generic.


I'd like to suggest DDD.

If you've got source code, you should check out QTCreator. Its debugger is similar to Visual Studio's, if you're familiar with that.

  • 1
    I've used DDD and wasn't a fan. I'll check out QtCreator though, thanks!
    – mrduclaw
    Mar 30 '13 at 2:41
  • DDD is great for displaying data structures, you can lay them out on a board (a light table of sorts). Hence data-display-debugger. Aug 2 '16 at 7:00
  • DDD looks weird and out-of-date at first glance, but it's really powerful.
    – Alexander
    Dec 13 '18 at 9:19
  • Ddd is, imo, poor and pretty much abandoned. It's certainly not in anyway powerful as all it is is a front end to gdb.
    – RichieHH
    Feb 27 at 23:41

Not GUI but a good replacement once you get used to it (and personally I think it's faster for most stuff) -> https://github.com/gdbinit/Gdbinit.

I remembered when I started *nix reversing and I had to face gdb for the first time. Hated it and +mammon original's gdbinit saved my day. These days I prefer gdb to most GUI debuggers.

Give it a try :-)

Full disclosure: I am the author of the tool.

  • 5
    You should write a disclosure that Gdbinit is a software you're maintaining... Apr 2 '13 at 13:00
  • 6
    So? It's free, available to anyone. Not exactly trying to sell anything here. Geez...!
    – fG-
    Apr 3 '13 at 3:24
  • 4
    @fg- That still might be some advertising that is not based on experience but solely on the fact you wrote that tool. Apr 6 '13 at 20:17
  • 2
    So you can't advertise your useful tools that solve problems and have to wait for others to do it? That's some really weird thinking mode for a problem solver "community".
    – fG-
    Apr 8 '13 at 9:59
  • 10
    @fG- please read the FAQ: reverseengineering.stackexchange.com/faq#promotion Apr 11 '13 at 12:28

I don't really like DDD, it's so 90's in it's GUI.

I would like to recommend KDBG, which is a KDE frontend to gdb. Besides, you might want to take a look at Cgdb, which is a curses extension for gdb.

Lately I came across Nemiver, it looks really promising.

  • Does KDBG work well for disassembling and debugging without source as well? Their screenshots showed source code only.
    – mrduclaw
    Mar 30 '13 at 17:25
  • I don't know, never tried it before... Mar 30 '13 at 17:35
  • "it's so 90's in it's GUI"... more like 80's
    – torvin
    Oct 31 '14 at 21:43
  • Is the appearance of the GUI the only downside?
    – Sunspawn
    Dec 18 '15 at 18:31

cgdb is also a great option if you use Vim.

cgdb shares a lot of commands with vim, such as regex search and many others. From the cgdb home page:

The keyboard interface is modeled after vim, so vim users should feel at home using cgdb.


I usually use Vim + gdb in CLI mode when coding etc. But sometimes a GUI is preferable.

One other option, beside the ones mentioned, is Code::Blocks. It uses GDB and CDB as back-end. For GDB you can select AT&T, Intel or custom for disassembly. It supports mixed mode as well as pure instructions listing. You can further set it up to evaluate variables (in code) under cursor etc.

There is only one memory dump window, but you can additionally enter raw GDB commands in Command line at bottom which gets printed to window – thus e.g. memory dumps.

It has a separate window for CPU registers, they are not directly editable, but you can set values by mentioned command line, as well as other values:

set $eax = 123
set var xyz = 'q'

Picture below shows it in action with source debugging on a KVM (Open link to view it in larger format).

One issue I have had with it is some GUI bugs etc. when I run it on Ubuntu 12 – UB 12 have version 10.10. But a compile and install of current release, 12.11, was painless.

E.g. for custom install path install (If your distribution does not have up to date version and you want to have both):

- Download (SVN or release).
- Unpack.
- ./configure --exec-prefix=/blahblah/codeblocks --prefix=/blahblah/codeblocks
- make
- sudo make install 2>&1 | tee my_install.log

Code::Blocks with GDB


This Dr Dobbs article shows in detail GUIs for debugging on Linux OS. I recommend the Qt-Creator called GDB debug based on Linux environment. Anyway the article only reviews debugging C++ code, but that is enough to show off GDBs debugging features.


There is Affnic Debugger GUI. It is not free but a lite version exists. It's available for Windows, Linux & MacOS.

From the official website,

Affinic Debugger GUI .aka. ADG, is designed as a graphical user interface for various debuggers. This build is specifically targeted on GDB, the GNU debugger. With the graphical windows, ADG can unleash the full power of debuggers by viewing multiple types of information within one view and maneuvering debuggers with easily clicking. ADG also provides an integrated command terminal for users to input debugger command directly. ADG is available on Linux/Windows/Mac OS X.


VisualStudio.Code (VS.Code) runs on Linux and has a "Native Debug" extension that lets you use gdb. It has very responsive UI. It's extremely light on resources. The experience somewhat approximates Visual Studio on Windows for C++ developers (there's no assembly view though). The main debug shortcuts are the same out of the box (F5, Shift-F5, F10, F11).

Installation is two-click (one to install VS.Code, the other to install the extension), great for someone coming from Windows Visual Studio and looking to be productive right away.


I will recommend UltraGDB, which is GDB GUI frontend and lightweight IDE based on Eclipse technology.


There's Voltron, which is an extensible Python debugger UI that supports LLDB, GDB, VDB, and WinDbg/CDB (via PyKD) and runs on macOS, Linux and Windows. For the first three it supports x86, x86_64, and arm with even arm64 support for lldb while adding even powerpc support for gdb.

The author also wrote a Binary Ninja plugin to integrate Voltron -- https://github.com/snare/binjatron -- which allows syncronized views.


You can use GDBFrontend. This is a very hackable GDB frontend.

Full disclosure: I am the developer.

  • It's rather nice. I liked it but ended up moving back to gef.
    – RichieHH
    Feb 27 at 23:43

Note that the following applies to source code debugging only.

CLion is an IDE using gdb. You still have the ability to type in commands but many features are seamlessly implemented in the GUI such as stepping, seeing currently active variables and setting breakpoints. Read more here.


Fast, self contained, documented and supported is the wonderful gef (GDB Enhanced Features)


I've written a new frontend called Seer. Give it a try and offer and suggestions.


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.