In a Unix terminal you can use the up arrow key to go back through previous commands, and it remembers these commands even if you close your terminal and open it again later. Is there a way to do this with gdb? When I close gdb it seems to forget previously used commands.
You can save gdb gdb command history
(gdb) set history save on
Google for "gdb save history" gives this link, which says you need to set history save on.
Related
I am trying to use gdb to debug caffe. I prefer to use the tui mode because it allows me to see the whole source code rather than just a single line. But there is a problem: whenever the program caffe outputs something on stderr, the output distorts the tui interface. See the below snapshot for an illustration:
Is this an inherent limitation of gdb tui or is there any way to solve this problem?
As suggested by #ks1322 you can press Ctrl-L to refresh the screen. Or define a hook in .gdbinit to refresh after every next command:
define hook-next
refresh
end
I never found a solution to such TUI annoyances, and eventually gave up and moved to more reliable methods that:
use the GDB Python API to get GDB data
output some pre-configured views to stdout after every stop instead of putting the terminal in a magic ncurses mode
GDB Dashboard is one such solution, and I have described it at: gdb split view with code
I know that I can
ask gdb to save my command history to a file, say gdb.history, by set history filename gdb.history and set history save on, and
ask it to log its output to another file, say gdb.output, by set logging file gdb.output and set logging on.
But how to require gdb to save both my command line inputs and its responding outputs to the same file, in the order of they occur in that GDB session?
I tried using the same file name in both history and logging command, it does not work, contents of that file will be overwrite by GDB command history when I quit from gdb.
You can try playing with logging plus "set trace-commands on". I don't know whether that will do what you want though. There's a bug open for this functionality: https://sourceware.org/bugzilla/show_bug.cgi?id=7219. I see I commented on it but I don't remember anything about it any more :)
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?
It's called the TUI (no kidding). Start for example with gdbtui or gdb -tui ...
Please also see this answer by Ciro Santilli. It wasn't available in 2012 to the best of my knowledge, but definitely worth a look.
You can trigger it dynamically by push ctrl+x and ctrl+a.
There are two variants of it.
to only see code Press
Press CTRL X together and then 1
To see both source and assembly
Press 'CTRL' 'X' together and then '2'
http://www.cs.fsu.edu/~baker/ada/gnat/html/gdb_23.html
A screen shot of the view with code and assembly.
Also check out this amazing Github project.
GDB Dashboard
https://github.com/cyrus-and/gdb-dashboard
GDB dashboard uses the official GDB Python API and prints the information that you want when GDB stops e.g. after a next, like the native display command.
Vs TUI:
more robust, as it just prints to stdout instead of putting the shell on a more magic curses state, e.g.:
vi mode in .inputrc causes problems: https://superuser.com/questions/180512/how-to-turn-off-gdb-tui/927728#927728
program stdout / stderr breaks your interface: GDB in TUI mode: how to deal with stderr's interaction with the ui
highly configurable from Python: you can select what you want to output and how big each section is depending on what you are debugging.
The most useful views are already implemented: source, assembly, registers, stack, memory, threads, expressions... but it should be easy to extend it with any information that is exposed on the GDB Python API.
TUI only allows showing two of source, assembly and registers and that is it. Unless you want to modify it's C source code of course ;-)
I believe that GDB should ship with a setup like that out of the box and turned on by default, it would attract much more users that way.
Oh, and the main developer, Andrea Cardaci, has been very responsive and awesome. Big kudos.
See also: How to highlight and color gdb output during interactive debugging?
You can also start it from the gdb shell using the command "-" (dash). Not sure how to dynamically turn it off though.
Type layout as a command in gdb and the split window will be shown.
When GDB is in the standard mode, using win will automatically switch in the TUI mode.
Other command for TUI mode:
info win
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.
There is also interface tool for GDB called cgdb. Even with some color highlighting.
"ESC" to switch to code view, "i" to switch back to gdb
tui mode was clearly inspired by emacs -- I discovered it by accident when I hit ^X-o, which switches among split windows in emacs -- I sometimes hit that absent-mindedly when what I should be doing is switching to a different program. Anyway, that leads to another feature not mentioned yet, that you can move the cursor from the code window (where you can scroll) to the command line, or vice versa, with ^X-o.
Problem A:
I start gdb in command line with "gdb test"
I press ctrl-x,ctrl-a before I do anything else
Then I set break point using "b main"
Then I start running the program using "r"
Till this point, if I press the Up arrow key the src window will not scroll. Instead, something will appear in my command window - "^[0A". If I try to refresh the screen with ctrl-l, "^L" is what appears in the command window.
I don't think this is supposed to happen. Under this situation I can't even quit tui mode with c-x,c-a ("^X^A" will appear instead). Am I doing something wrong? I realize this problem occurs so long as I use the "run" command inside the TUI interface. I can, however, use the run command in TUI if I start gdb with "gdb -tui"
Problem B
I can't see the output of my program in TUI mode. GDB's own output can be seen, but not that of the program being debugged. This occurs both when I enter TUI using ctrl-x,ctrl-a and when using -tui command-line option.
Is there any way to fix this?
I've read some TUI articles on the net and some people seem to use TUI "exclusively". I suppose TUI can work properly, it's just there's a set of rules that must be carefully followed?
EDIT: I use gnome-terminal in ubuntu 11.04
Run gdb with -tui option instead (https://bbs.archlinux.org/viewtopic.php?id=112660)
~/.inputrc was the culprit in GDB 7.7 because of:
set editing-mode vi
set keymap vi
If I remove those lines it works.
This seems to be mentioned at in the following bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15163
I have requested a workaround at https://sourceware.org/ml/gdb/2015-06/msg00009.html and Andrew Burgess replied that he had just submitted a well received patch to add:
tui enable
tui disable
so in future versions we should have commands as an alternative to the shortcuts.
But then I saw the light and moved from TUI to GDB Dashboard: https://github.com/cyrus-and/gdb-dashboard which is simply more powerful and less buggy. See also: How to highlight and color gdb output during interactive debugging?
Change your terminal to get rid of your first problem. I used to use gnome-terminal my self, but then changed to terminator. Some terminals don't support keys like Alt sometimes (used to experience this in vim with some Alt+something maps)
You can change forcus to another window by 'focus winName', in your case, use 'focus src'
got this from here
Not sure about your 2nd problem. Good luck!
I think you are looking for, "focus next." it switches you among (there can be more than two) the windows. I'm sure there is a short-cut for this too. Please note, this is almost the same answer as user1888039, so if you agree you should up-vote that answer.
Problem A:
Use Ctrl+X then press a to enter or exit TUI mode.
Or as you mentioned run gdb -tui
Problem B:
Note that your program print could be ran over by the (gdb) prompt. In other words, it is possible that your program prints but the " (gdb)" is printed over it after.
To easily check if this is indeed the case, try to print either a line longer than 6 characters or multiple lines each time.
You should see part of your print.
I've just installed Pyclewn. It works and shows variables and etc. But it doesn't show my program's output and when my program wants to input something, it doesn't do anything(I can write ":C run output" and it works. but not with standard I/O.
There was something in its documentation: http://pyclewn.sourceforge.net/_static/pyclewn.html
But I didn't understand what it says.
P.S: I've done that. Now I want to map for example to run those commands. but because the "nn" in /dev/pts/nn may vary, I should manually enter the number(see it from the xterm opened). I also have another problem when I map a key to a sequence of gdb commands, it says gdb is busy, I can add ":sleep 100m" between commands and the problem will be soved. but in the documentation it says that I should enable async option. but when I run pyclewn from vim with :Pyclewn command I don't know how to enable the async option.
You should use inferior_tty.py to create a terminal to be used with the program being debugged.
Abridged summary (most relevant bits only) from the FAQ:
:Cshell setsid xterm -e inferior_tty.py &
Determine what the name of the tty to be used is from this newly spawned window, then:
:Cset inferior-tty /dev/pts/nn
Or just start pyclewn from a terminal and it will automatically grab that terminal for input and output.
E.g:
pyclewn -c "main.cc other.h other.cc"