I am writing gdb command scripts to simplify the debugging. One of the problems I have
is that I am setting a breakpoint, and I want to disable it afterwards, and only enable it after another breakpoint is hit.
What I want to do is this
$my_break_number = break SomeFile.cpp:231
disable $my_break_number
but unfortunately gdb doesn't work this way. I have read the manual, but I cannot find any information on how to do this. Hopefully there is some information I have missed.
gdb will automatically set a convenience variable $bpnum with the last set breakpoint number.
You can possibly use that after setting a breakpoint to disable it (I haven't tested when a breakpoint is ambiguous and creates multiple breakpoints, I think it will work and disable all breakpoint locations created.)
see: http://sourceware.org/gdb/current/onlinedocs/gdb/Set-Breaks.html#Set-Breaks
if you need to use the breakpoint number from commands, that is probably not what you want, but it works for the question as specified.
It sounds like you may want to use the Python GDB scripting, which gives you a lot better programmatic access to breakpoints than what is possible with "regular" command scripts.
Also info breakpoints gives useful information such as:
number of breakpoint, how many time the breakpoint was hit, address in memory, what function is it in, file and line number of breakpoint
Related
I want to improve the already good analysis of the PyInstaller issue https://github.com/pyinstaller/pyinstaller/issues/2355. For that I need to either catch all errors or set a specific break point with LLDB.
On GitHub I stated
For starters one would essentially just need a break point that catches all errors and then dump the call stack.
I tried break set -E C++, breakpoint set --selector __cxa_throw: [...] but nope, doesn't stop.
The execution does stop i.e. hit the break point if I do b Get but there are way too many functions this selector affects.
To conclude, how can I make the executable, available at http://frightanic.com/misc/hello-world, stop right when that error at ./src/common/stdpbase.cpp(62) occurs?
--selector specifies a break on an ObjC selector name. So I wouldn't expect that one to work. I don't know how these check macros work, but the one getting tripped says it returns a value in non-debug or stops in the debugger for debug, so I'd be surprised if it throws a C++ exception. The fact that the C++ exception breakpoint isn't getting tripped bears that out. You can specify a class::method to lldb's breakpoint. So you might try:
(lldb) break set -n wxStandardPathsBase::Get
That should narrow the breakpoint down. Of course if you have debug information for the wxwidgets, you should be able to set a file & line breakpoint which will also be more precise.
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 have to debug a code in which i want to debug only after certain number of iterations. For eg. one debugging after 1000 iterations, the next after 8000+ iterations. Since I've a lot of breakpoints, changing the condition for each one is tedious.
Yes, you can do that:
Use set confirm off so GDB doesn't prompt you with "are you sure you want to do that" prompts
Use disable to disable all breakpoints
Add a new breakpoint at the start of the loop
Attach enable command to the new breakpoint (this will re-enable all other breakpoints when this one fires)
Set ignore count on the new breakpoint to 1000.
Enjoy your new debugging prowess.
Is there any way in gdb to redefine the location of a breakpoint without having to disable/delete it and make another one, say, two lines above it which is invariably assigned a different number even if we delete the previous one?
Is there any way in gdb to redefine the location of a breakpoint without having to disable/delete it and make another one
No.
Presumably you care about keeping the old breakpoint number because you've attached commands to disable and enable that breakpoint to other breakpoints. If so, you can use save breakpoints command to save breakpoint definitions to a file, adjust the location of the breakpoint there with an editor, then restart GDB and use source command to reload the breakpoints.
I'm debugging multi-threaded code and I would just like to know if a line has been reached without it stopping but I don't want to start adding print statements everywhere.
Is this possible? Thanks!
You can attach commands to a breakpoint in gdb with the 'commands' command. One of those commands can be 'continue'.
You may be looking for tracepoints. These capture variable values without stopping execution.
http://sourceware.org/gdb/onlinedocs/gdb/Tracepoints.html