I'm using some third party macros in gdb, which take a long time to run.
I keep pressing Enter, because my muscle memory does that.
This causes the macro to run again.
Is there any way that I can persuade gdb not to run the previous command on pressing Enter?
I found the dont-repeat documentation, but it seems that I have to add it to the user-defined command. These are third-party commands, and I don't particularly want to edit all of them.
Is there any way to turn this behaviour off globally? Or for specific commands (possibly with a wildcard/regex)?
These are third-party commands, and I don't particularly want to edit
all of them.
For a specific command you can define pre hook, turning off repeating last command. This will let you to avoid editing them. For example you can define such pre hook for continue command:
(gdb) c
The program is not being run.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb) define hook-continue
Type commands for definition of "hook-continue".
End with a line saying just "end".
>dont-repeat
>end
(gdb) c
The program is not being run.
(gdb)
(gdb)
(gdb)
(gdb)
(gdb)
See hooks doc.
Related
Some debuggers (like pdb) automatically break at your first line of code, then allow you to add breakpoints as needed. I'd really like to have that functionality with gdb. (I need to trace code execution through a huge codebase, and none of my guesses as to where to set a breakpoint have been correct, so the program just runs through to the end.) I've read that you can get similar functionality with gdb's starti command, but gdb takes it a little too literally: it stops on the VERY first line of the program where the linking information is. How can I move past this and actually step into my program? I've tried running the s command, but nothing looks familiar.
Here's a picture of what I see when I run starti.
Use start, not starti. start puts a temporary breakpoint on your main() function and begins executing. It should start at the beginning of your program proper.
I start gdb as following: gdb --args parentExecutable LotsOfArgsForParent
I also run: set follow-fork-mode child
parentExecutable forks at some point and executes a childExecutable with some arguments. I debug the child for a while. Then, I use the run command of gdb to restart the parentExecutable with the arguments given in the beginning. However, instead, the childExecutable restarts -- from scratch without any arguments. How can I make gdb start the parent with the arguments provided in the beginning?
There are actually two modes to pay attention to in this scenario. One mode is follow-fork-mode, which tells gdb what to do when the inferior forks. However, there is also follow-exec-mode, which tells gdb how to handle an exec call.
The default setting for follow-exec-mode is same, which tells gdb to reuse the current inferior for the exec'd process. In this situation, once the child process stops, run will re-run the child.
What you want, instead, is set follow-exec-mode new. In this mode, gdb will make a new inferior in response to the exec. Then, when you want to re-run the original executable, you can switch back to the first inferior (use info inferior to get a list and the inferior command to select one). Then run will re-run the original.
Another way to do all this is multi-inferior debugging, using set detach-on-fork off. However, in my experience, this mode is still a bit flaky. Once it works, though, I think it will be the preferred approach.
I'm currently debugging syslinux (a boot loader) through the gdb stub of qemu.
Recently, I wrote some gdb commands that (un)load the debug symbols everytime a module is dynamically (un)loaded. In order not to disrupt the execution, I ended the commands with continue.
break com32/lib/sys/module/elf_module.c:282
commands
silent
python
name = gdb.parse_and_eval("module->name").string()
addr = int(str(gdb.parse_and_eval("module->base_addr")), 0)
gdb.execute("load-syslinux-module %s 0x%08x" % (name, addr))
end
continue
end
However, when stepping through the code line by line, if the next or step command makes the execution hit the breakpoint, the breakpoints takes precedence, the commands are executed, including the continue. And the execution continue irrespectively of the line-by-line debugging I was doign. This also happen if I try to step over the function that has this breakpoint.
How can I keep (un)loading the debug symbols on the fly while not interfering with the debugging?
Is there an alternative to the continue command? Maybe using breakpoints isn't the right way? I'd take any solution.
This can't be done from the gdb CLI. However, it is easy to do from Python.
In Python the simplest way is to define one's own gdb.Breakpoint subclass, and define the stop method on it. This method can do the work you like, then return False to tell gdb to continue.
The stop facility was designed to avoid the problems with cont in commands. See the documentation for more details.
I am trying to debug a service. The usual procedure is to start the service and attach gdb to the process. But I want to debug the code when the service is still starting up. It takes a while for gdb to load the libraries, and the required code has executed before I can put the breakpoints. Any idea how to do it? Thanks!
Let's assume your service is called "myservice.exe"
If you can get on the box that the code is actually running on, then I would do the following:
$ gdb myservice.exe
(gdb) break myclass:myfunction
(gdb) run
This should get you what you want.
Note: if you can't run gdb directly, then put a "sleep" statement for 1 minute at the very start (before the part you want to debug) - that should allow you to connect before it starts the sensitive code.
I decided to find out how our C/C+ *nix practitioners use the gdb debugger.
Here is what I typically use:
b - break filename.c:line #, function, filename.cpp:function, className::Member
n, c, s -- next continue step
gdb program name => set breakpoints ==> run [parameter list] (I do this to set break points before the program starts)
l - to list the surrounding source code.
attach processID
6 break [location]
gdb programName corefile.core (to examine why app crashed)
I also sometimes set breakpoint at exit function (break exit) to examine program stacks
info b to examine all the breakpoints
clear [breakpoints list ]
How do you use it?
Besides things that have already been posted i also use:
a .gdbinit file for STL containers
signal SIGNAL noprint nostop for some custom signals that are of no real interest when debugging
C-Casts to dereference pointers
catchpoints (catch throw, catch catch)
condition for conditional break- and watchpoints
rarely gdbserver for remote debugging
gdb program coredump, for those embarassing segfaults ;)
PS: One reason i personally love gdb btw. is that it supports tab-completion for nearly everything (gdb commands, symbols in the symbol table, functions, memberfunctions etc.). This is a fairly good productivity boost in my opinion.
Scripting is a nice GDB feature.
First you set a breakpoint, like: b someFunction\n.
Then you run command: commands\n. GDB will ask for commands for that breakpoint.
Common scenario is to print some value and then continue, so you will enter: p someVar\n continue\n.
To end the script press: Ctrl-D
After running program you will see your script executed occasionally when the breakpoint occurs.
Most useful gdb commands in my opinion (aside from all already listed):
info threads - information about threads
thread N - switch to thread N
catch throw - break on any thrown exception. Useful when you caught the bug only after the stack unwound.
printf,print - examine any and all expressions, printf accepts C-style formatting specifiers
Finally, if debugging over a slow link, the text UI might be of use. To use it, start gdb with the --tui command-line switch.
gdb is not my speciality, but here is what i use:
bt list a stack
up, down moving in a stack
until continue until a line with greater number than current is reached -- for exiting loops
watch [expr] break the program when expr changes
... but mostly i use ddd as a frontend to gdb
Type Ctrl-X Ctrl-A to open a simple window with source preview.
Some time ago I found cgdb:
http://cgdb.sourceforge.net/
This is a curses (color console) based frontend for gdb that made my life a lot happier when I was restricted to debugging in a console window.
See the user guide at http://sources.redhat.com/gdb/current/onlinedocs/gdb_toc.html.
There are also a couple of uses that are not directly connected with debugging. For example it
can be used for C expression evaluation:
(gdb) printf "%lu\n", (unsigned long)(-3L)
4294967293
i use the gdb -tui switch for a great 'text user interface' (a kind of gui in text mode). It supports multiple windows and is generally much more friendly than using the 'list' command (since it shows the source in a sep window)
Beginners using gdb will feel it as tough. But there GUI based tool DDD(Data Display Debugger) which is same as gdb. u have a console in the bottom to run gdb commands and top 3/4th portion would be the code. U ll have the option to learn and understand the commands and the flow excatly