Is it possible to change the location of an existing GDB breakpoint?
I've set one on a particular line, and then added a condition to it. I would like to move it to a different line number, but retain the condition without having to destroy it and retype the condition.
I'm using GDB 7.5 on RedHat Enterprise Linux 5 64bit.
Any help much appreciated.
It is not possible to do this.
It would be a nice addition, but nobody has implemented it yet.
You can use "save breakpoints" and then edit the result and source it. This may be handy if the condition is very complicated.
How about the following?
break +offset
break -offset
Set a breakpoint some number of lines forward or back from the position at which execution stopped in the currently selected frame.
(see http://www.ofb.net/gnu/gdb/gdb_29.html#SEC29)
Related
I have several breakpoints set up. They are numbered from 6 to 6.38.
I want to delete a range. Based on this I can do it. However when I
(gdb) delete breakpoints 6-6.2
I get a following response
inverted range
When I
(gdb) delete breakpoints 6.1-6.2
I get
warning: bad breakpoint number at or near '6.1-6.2'
I googled in many places but I wasn't able to find a proper way to specify ranges. Does anybody know what is the right way to specify ranges?
I would really appreciate any help on this.
In gdb, when a breakpoint has multiple locations, you can't delete just an individual location. This is a bit of an oddity in the gdb CLI.
This is why delete 6.1-6.3 doesn't work. The error message could certainly be better here.
One thing you can do instead is disable just the locations you don't want. Offhand I am not sure if disable 6.1-6.3 will work -- you might have to type out disable 6.1, disable 6.2, etc.
Every time I run a project in debug mode, I get 4 consecutive breaks at the start that I have to hit continue for each time. They are in the same file at the same point.
It would be great if I could say to simply ignore these since they don't impact functionality.
The obviously better route would be to try to resolve it so it doesn't cause a break/continue prompt but I think that's more effort that it's worth at the moment.
It would be great if the solution related only to my specific environment so I wouldn't have to undo/do it each time I pull/push a build.
Try to use break point condition or break point filer.
I am trying to use gdb with MySQL source code which is written in C/C++. In mysql-test/t, I create a custom test case file, say, example.test and then debug it by using the following line of code
/mysql-test-run --gdb example
Now I want to see the flow of execution as it changes from one function in a file to another in some different file. I am not sure of how the execution changes, so I can't pre define the break points. Any solution to how I can get to see the flow with multiple files of source code?
You can use the next directive to take line-by-line steps through the source. When appropriate, you can use the step directive to take steps "into" the function(s) being called on the current line.
A reasonable method would be to do next until you think you only just pass the externally visible behavior you're looking for. Then start over, stopping at the line right before you saw the behavior last time. Then step this time. Repeat as necessary until you find the code you're looking for. If you believe that it's encountering some sort of deadlock, it's significantly easier -- just interrupt (Ctrl-C) the program when you think it's stuck and it should stop right in the interesting spot.
In general, walking through the source you'll build up some places you think are interesting. You can note the source file and line number and/or function names as appropriate and set those breakpoints directly in the future to avoid tedious next/next/next business.
The reason why I'm asking this, is because I'm coding in C++, in putty/ssh and I like the fact that I can code from pretty much everywhere without having to install anything.
So I'd like to have something that could help me debugging (viewing LIVE value of a variable, breakpoints, etc)
If you think that there's no such thing in this world, is there any good technique I could use to debug in command line?
Thanks
I've used gdb for command line debugging in the past with success:
http://www.gnu.org/software/gdb/
A decent tutorial can be found at:
http://www.cs.cmu.edu/~gilpin/tutorial/
vimgdb will give what you want. I've used it for about one year. The most interesting feature is:
Hightlight current line
List item
Can show disassembly code
Step into, Step over
inspect variables, memory address
Run all the underlying gdb command is possible
And, of course, set breakpoint, conditional breakpoint etc.
Highly customizable by vim key mapping and scripts.
Actually I use checkinstall to make an rpm for it, and installed it everywhere when I need to debug on the box.
I think it have the most important features I want from a visual debugger.
Have you tried gdb ? That's pretty much the command line debugger, but it's no vim plugin.
You have a script to do that: http://www.vim.org/scripts/script.php?script_id=1954
In my humble opinion, Vim is not designed to do such things and it is a bad idea to do so.
GDB, at least as it's configured by default on my Ubuntu 9.04 box, doesn't handle multi-line statements well. When I'm stepping through code, GDB only displays the last line of the current statement, even if that statement spans multiple lines.
I'm aware that I could use DDD or emacs as a frontend for GDB, but I'd prefer to solve this problem within GDB, if that's possible.
Does anyone know if there's a way to get GDB to do the right thing here?
How about running GDB with the text user interface?
gdb -tui
It makes a world of difference to the ease of use of GDB.
I'm afraid the answer is "no, there is no way to get gdb to do what you want".
The line info in the symbol tables associates each code instruction with a single
source line (not a source statement). gdb has no way of knowing that several
source lines are associated with the same source statement.