Pretty awesome - the only thing I would change is for the ability to switch to Intel syntax for the disassembly. Maybe I'm the only one - but I find intel syntax easier to read.
But another thing I can say from experience is that GDB Asm-level debugging seems to be more of an afterthought and everything doesn't make as much sense as e.g. OllyDbg or even the old MS-DOS DEBUG. The behaviour of some commands like "disassemble" is perplexing at best[1]. It was really meant for use with higher-level languages.
My experience of gdb asm-level debugging is that it is incredibly buggy and dumps core at the drop of a hat. It's not fit for purpose. I've taken to using it to get a disassembly listing of the problematic code and simply analyzing it in an editor, rather than risk doing anything in gdb.
This is super sweet! I've recently been messing around a lot in C/C++ with GDB to spelunk through, and this kind of wrapper makes a lot of things immediately visible that I wish were there by default.
This looks great but im curious, when do people actually use gdb shell instead of debugging in your IDE? I only do it during emergencies, such as a one in a million bug happened on a server which I can only access over SSH and this might be my only chance to find it. Maybe this tool could make that experience a bit closer to what I'm used to when using an ide.
I use GDB interactively pretty often, generally when working on cross-platform code.
Basically, I can't find any IDEs I like for linux, and the overhead of running a big IDE in a VM (which is where I do most of my cross-platform testing; I principally develop on windows) makes them painful to use.
http://emacs-fu.blogspot.com/2009/02/fancy-debugging-with-gd...