show - gdb split view with code
source window (7)
You and also start it from the gdb shell using the command "-" (dash). Not sure how to dynamically turn it off though.
I was just debugging a program in gdb and somehow I found a new feature I've never seen or even heard of before, a split view where I can see and browse the code in addition to giving commands:
What is this? What did I do, or, more specifically, how can I get this split-screen mode again? Is there a name for this mode, or somewhere I can read about how to use it?
You can trigger it dynamically by push ctrl+x and ctrl+a.
There are two variants of it.
- to only see code Press
X together and then
- To see both source and assembly
Press 'CTRL' 'X' together and then '2'
A screen shot of the view with code and assembly.
It's called the TUI (no kidding). Start for example with
gdb -tui ...
When GDB is in the standard mode, using
win will automatically switch in the TUI mode.
Other command for TUI mode:
List and give the size of all displayed windows.
focus next | prev | src | asm | regs | split
Set the focus to the named window. This command allows to change the active window so that scrolling keys can be affected to another window.
Read here form more help.
I had the exact same problem when running gdb under emacs: the *gud* window was not responding to commands. However, ndk-gdb was working well in a shell. To make it work under the emacs gud UI, I had to modify the ndk-gdb script a bit.
On call to GDB (last line), do this:
$GDBCLIENT --annotate=3 -x `native_path $GDBSETUP`
The --annotate=3 option is mandatory for emacs gud interface, it cannot work without it (that's why *gud* was not responding).
But you're halfway. Now it will work, but only if you invoke ndk-gdb while in a buffer from a file at the root of the project (like AndroidManifest.xml). Since this is very unlikely most of the time because you are a C/C++ programmer and the sources you're working on are under the jni directory or deeper, you need to do a little more. The ndk-gdb script is a bit buggy and it will happily confuse you on this one (and gdb itself won't help much either).
Search the script for "PROJECT=$OPTION_PROJECT". You will be in a long if...else...fi clause which is in charge of finding the root of the project (if it has not been given with the --project option, though doing so WILL NOT resolve the issue I talk about, see below). After the fi, add this line:
For some obscure reason, the script DOES NOT cd to the project root directory. This leads to very wrong behaviour when dealing with the gdb.setup file where the script assumes to be at project root. Adding this line will fix it.
Make sure you call ndk-gdb within emacs with the usual command:
(gdb "ndk-gdb ...")
Do not use gud-gdb (oddly, this is old emacs way of using gdb and has nothing to do with the nice UI you're searching for). Replace ... with your arguments, (concat ...) or anything you wish. I strongly recommend to use the --project option anyway. If you don't and you are in a buffer for a file which is out of the project, the script won't find the root. Worse, if you're in a file in another Android project, it will find the root of that project instead (maybe even copying gdb.setup and stuffs into it before failing the gdb session). So give that damn --project option. If you're using emacs desktop command set, do this:
(gdb (concat "ndk-gdb --project=" desktop-dirname ...))
(assuming your .emacs.desktop is at the root of the project, of course).
Now you can finally debug with gud UI, setting breakpoints at source level. Note that I use emacs 23.3.1 (gdb-ui.el), so there is no need to have 24 for this to work.