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.
Related
I am dealing with a large code base with tons of globals. Under some peculiar set of data it produces the wrong result. I wanted to automatically run few scenarios with gdb in automatic step-by-step execution and periodical dumping
of some values and recording the tracing in some file. Doing it manually will ruin my sight and my brain. I speculate that there is some globals mess-up. How to do this automatically? Use some scripting. All this is in RH linux.
Thanks in advance.
tried to do this manually using conditional breaks, but gave up after a while
I wanted to automatically run few scenarios with gdb in automatic step-by-step execution and periodical dumping of some values and recording the tracing in some file.
It may be significantly more effective to run the program under reverse debugger (such as rr), and trace the wrong result back to its source.
How to do this automatically?
You can't do automatically what you can't express as an algorithm, and you haven't described an algorithm you want to use. If it's something like "stop every 100 times foo is called and print the values of these 500 globals", than that's trivially automatable with GDB.
More complicated algorithms are possible with the use of embedded Python.
In the .gdbinit file in your home folder add
add-auto-load-safe-path /path_to_the_folder_containing_your_executable/
Now you can create another .gdbinit file in the same folder where your executable is that will be loaded when you start gdb from there (the .gdbinit file in your home that is also read - useful if you have nice stuff there such as loading pretty printers).
In this .gdbinit file, add the code below
file your_executable_name
start
# Optional
set args "<any command line parameters you program might need>"
# xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Add gdb commands below to set breakpoints, print variable values, etc
# xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
run
Gdb is very powerful and I'll list a few things that might help this automation.
You can set breakpoints with b filename.ext:line_number or b function_name
You can use commands breakpoint_number (see here) and then list commands that should be run after this breakpoint is hit. Use end to finish the commands
You know the breakpoint number, since they are created sequencially (note that the start will count as a breakpoint and thus the first one you add will be breakpoint 2)
You can use convenience variables to store useful things such as the address of an important object
The python api is very powerful
One idea is that you can save the address of the important global variables (if they are not always accessible) using convenience variables. For instance, add a breakpoint where this global variable is and then add to this breakpoint the command to save the address of this variable to a convenience variable followed by continue (with continue you will not see gdb stopping there).
set $var1 = &myglobal
continue
You might want to also delete this breakpoint with delete breakpoint_number before continue to avoid stopping at this breakpoint again.
Then as long is the object exists you can inspect it using p $var1 or p $var1->something when the program is stopped at a different breakpoint where myglobal might not be directly accessible.
In the commands that you add to be run when a breakpoint is hit you can do things such as echo message explaining where you are, p some_var to see the values of variables or even python some_complicated_python_code.
In the case you want to use python for more power it is worth reading the section about it in the manual. Let-me give you one example. Suppose one of your global variables was stored in a convenience variable called "$myvar". Then you can pass it to the python interpreter with
python myvar = gdb.parse_and_eval("$myvar")
You can also pass any variable in the current scope to parse_and_eval.
Now, suppose this global variable stores an object of a class with a "n_elem" attribute you want to check. You can print it with
python print(myvar["n_elem"])
You can also create a python file in the same folder and use
python from my_python_file import *
to import functions defined there.
With these gdb features you can pretty much automate whatever you might need.
I set a breakpoint and set its conditions and some other commands. Now I realize that I should had set it a few lines ahead. How can I change the line of the breakpoint without deleting it and losing its settings?
How can I change the line of the breakpoint without deleting it and losing its settings?
You can't.
What you can do is use save breakpoints /tmp/bp.txt command to save current settings for all breakpoints, edit the /tmp/bp.txt file to update the line info (or anything else), and finally delete to remove current breakpoints and source /tmp/bp.txt to reload them.
Considering that you will probably want to do that on many occasions, I suggest adding the following to your .gdbinit:
define loadbp
delete breakpoints
source .gdbbp
end
document loadbp
Set stored breakpoints after deleting any current breakpoints.
The breakpoints to load (set) are expected in ./.gdbbp which is the file created by savebp, but can
be edited manually.
Some breakpoints may not be set because the needed shared object hasn't been loaded yet. gdb
doesn't prompt when such breakpoint commands are not set interactively. Consequently, it may be
necessary to run this command again, once the shared object has been loaded. To account for cases
in which shared objects are loaded automatically by the dynamic loader, this command also sets a
breakpoint in main. This ensures that there is an early opportunity to call this command again to
set shared object breakpoints.
end
define savebp
save breakpoints .gdbbp
end
document savebp
Store current breakpoints in .gdbbp for retrieval using loadbp.
end
To use those commands, you need to source .gdbinit or restart gdb. Then, type savebp and hit Enter at the gdb command prompt, edit ./.gdbbp as desired, then type loadbp and hit Enter at the gdb command prompt.
Note that, as written, those commands save and load .gdbbp relative to the current directory. Usually, that's the directory from which you started gdb, but you can change it from within gdb, so pay attention to where the file is saved. (You can run the pwd command at the gdb command prompt to see what the current directory is.)
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.
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
I've read the thread break whenever a file(or class) is entered. And I now understood the basic mechanism how to automatically set breakpoints in the classes. However, the solution that thread provided is focused on .net framework. My problem is how to deal with it in standard C++. We use vc 10 compiler on windows 7 platform.
Besides, we prefer methods which do not need recompile when we rechoose the class which we want to inspect since it is a huge project and recompilation takes a lot of time.
Thanks in advanceļ¼
You can do it from the IDE:
http://blogs.msdn.com/b/habibh/archive/2009/09/10/class-breakpoint-how-to-set-a-breakpoint-on-a-c-class-in-the-visual-studio-debugger.aspx
The answer Emile Cormier gives is a good solution. When I try to add a breakpoint "Stack::* " as the link says, I found there is no red point on the left of code lines until I start debugging the program. After stopping the program, the red points disappear, but the break point window will keep track of every breakpoint and you can turn to the code by double clicking the breakpoint in the breakpoint window.
As far as i know, you can only set memory breakpoints (break whenever the contents of a certain memory address is read/written) and then manual breakpoints (break on a certain line of code).
Your best bet may be to set a breakpoint at the beginning of the function call(s) you want to debug.