I'm having problems getting gdb to pause execution flow under NetBeans. The pause button doesn't appear to work at all. From this answer, I suspect it may be a problem with what text gdb is actually receiving as input (I'm under Windows/Mingw32 using IIRC msys bash). But this is just a guess.
I don't know where to view what is happening with gdb (input or output). I see a few mentions of it in the debugger console but not sure if that counts for anything. I'd post that log here but it is rather large.
This is apparently a general problem with Windows/Netbeans, for which detail can be found on one of the NetBeans site pages (can't remember which).
Related
Years ago, when I last had call to use GDB to debug a Linux server, I seem to remember seeing a listing of the code that was being executed. Perhaps it was just the current line +/- five lines or so. I think i also remember it redrawing the entire console, every time I executed a command, so that the code listing was always at the top of the screen.
Now that I am once again in need of GDB's assistance, is my memory playing cruel tricks on me? Or does such a mode actually exist?
The documentation I'm finding online just points me at the 'l' command to list code. That looks like it has some potential, but there doesn't seem to be a way to get it to dynamically update as I step/next my way through the code.
If it's significant, I'm running Ubuntu on a dedicated Linux machine, and (since the program uses OpenGL) the actual debugging is going on inside a Weston Compositor terminal window.
I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?
At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?
Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end
My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit
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 am using emacs and autotools, to write and compile c/c++ sources on linux.
I am using gdb via GUD in emacs.
I have defined for convenience: F7:compile, F10:gud-next, F11:gud-step, F5:gud-cont, F9:gud-tbreak, F8:gud-until, F4:gud-print.
I am mainly interested in debugging c/c++ source code on linux from emacs and I would like to get the most gdb can give.
Unfortunately I am using only F4 which prints the variable under cursor.
So my question is how do you guys debug the source code ?
What programs do you use ?
What key bindings (functionality) do you use mostly ?
What do you need the debugger to do for you ?
If you do weird stuff it doesn't matter. I would like to know everything to boost my speed a bit here.
Thanks in advance.
Mihai
I use the M-x gdb... commands to select the windows I need, then I use the gdb prompt.
I often set break points with C-x SPC on the source line once gdb is underway,
You'll get the most out of gdb by using the command line instead of key bindings. The most useful commands that I use:
bt - prints a backtrace; helpful to know full context of where you are
s, n, cont - step, next, continue
run - very useful for starting over within the same session
watch - sets a watchpoint; useful for catching when a value changes
call - invoke a function
display - Print a value every time the program stops.
valgrind is perfect for detecting memory errors. Most of the times you are given the exact location of where the error is.
gdb is nice too, but doesn't have great interface, so it is best to be used with some kind of gui like ddd or Eclipse for instance (yes, I am using gdb with Eclipse, it has built in support for it).
I only use the debugger to get a backtrace on a segmentation fault. For everything else I use printf debugging.