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?

  • 1
    This post might get closed as not constructive, as the answers would be subjective. Adding requirements to your question will improve it. – user187 Mar 30 '13 at 7:44
  • 2
    @CamilStaps I updated the question to be less subjective. – mrduclaw Mar 30 '13 at 17:21
  • 3
    Debuggers are an essential part of reverse engineering, right along with disassemblers. If this is not the forum to ask about toolsets, where is? – omghai2u Mar 30 '13 at 18:41
  • 2
    @omghai2u The initial post asked for a decent gui. Decency cannot be objectively measured for GUIs which would lead to basically listing all possible GUIs here, rather than those that satisfy certain requirements. In its current form, the question specifies some criteria for objectively evaluating the answers thus making it somewhat constructive. – asheeshr Mar 31 '13 at 3:15
  • @AshRj ah, I see what you mean now. My mistake, apologies. – omghai2u Mar 31 '13 at 3:18

16 Answers 16


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 and browsers (Linux, macOS, and Windows)


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
  • python27 on win7 gives lot of errors on startup: SyntaxError: Non-ASCII character '\xe2', SyntaxError: invalid syntax: history save. Screenshot is impressive, but can't use it. – mosh Jan 6 '17 at 14:40
  • There is an issue filed on the github page with a fix, check it out: github.com/cyrus-and/gdb-dashboard/issues/52 If it still doesn't fix it, you should ask a question, or file a new issue with the developer on that github page. Good luck! – cs01 Jan 7 '17 at 5:11
  • That actually looks really nice! – mrduclaw Jan 23 '17 at 5:42
  • Tried it, I always get "No gdb response received after 10 seconds. This usually indicates an error." both with Chromium and Firefox with the default gdb in Ubuntu 16.04, when trying to debug a program. But with gdb 8.1, compiled with python 3 support it works much better (I passed PYTHON=python3 and -with-python=python3 to ./configure when building gdb and then run make && make install) (gdb compiled with python 2 produces a lot of errors during debugging sessions) – Gerardo Hernandez Apr 13 '18 at 17:44
  • 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 at 11:06

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

  • That's pretty cool, thanks for the suggestion! – mrduclaw Mar 30 '13 at 3:21

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)

  • This is Spacemacs and not GNU Emacs right ? – bertfred Oct 12 '16 at 9:39
  • 1
    Nope. This is plain 'ol GNU Emacs, I just have mine styled to look like this. Nothing I mentioned above is specific to my configuration. (And actually, Spacemacs is just a set of Emacs configs too, but I have no clue if it changes GDB usage any) – Archenoth Oct 12 '16 at 16:34

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.

  • 2
    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
  • 4
    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. – joxeankoret 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. – Roman Plášil 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

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 :-)

  • 5
    You should write a disclosure that Gdbinit is a software you're maintaining... – Mellowcandle Apr 2 '13 at 13:00
  • 4
    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. – heinrich5991 Apr 6 '13 at 20:17
  • 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
  • 8
    @fG- please read the FAQ: reverseengineering.stackexchange.com/faq#promotion – Mellowcandle 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... – Mellowcandle 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.

  • 7
    Why? more details, please! – Ange May 8 '13 at 16:16
  • 3
    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:54
  • 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." – jlhonora May 15 '13 at 20:25
  • 2
    @jlhonora Ideally you should add the details to the answer rather than post in the comments. Comments are mainly for dicussing how to improve your answer. – cb88 May 28 '13 at 10:49

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.


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


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.


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.


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.


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.

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.