If I set up a break point and if GDB hits the break points, then it shows the line of the code. If I enter n or next, then GDB prints out the next line of the code.
I was wondering if there is a way I can trace the actual line of code being executed through GDB.
For example, if I enter n or next 100 times then I will get traces of 100 lines of code. I want to do this automatically not by entering n or next.
Note that collecting next trace like you appear to desire is exceedingly unlikely to help you debug actual problem in any realistically sized program: most of the time programs spend in loops, and executing next repeatedly will just give you a never-ending stream of loop repetitions.
That said, you can achieve what you want like this:
(gdb) shell perl -e 'print "n\n" x 100' > gdb.cmd
(gdb) source gdb.cmd
put a breakpoint 100 lines from your current position and continue the execution
Related
I have two breakpoints A and B. And I'd like to count how many instances of A occur before B is hit. The thing is A occurs quite a bit (>1000) so i can't manually continue and iterate. A can also occur after B so I can't run a program to completion to find out the hit counts. Is there an automatic way to do this?
You can do this pretty easily with an auto-continue breakpoint at A and commands on breakpoint B. In the simplest approach, the breakpoint on A would look like:
break set <HoweverYouSpecifyA> --auto-continue 1 -N BreakpointA
Then the breakpoint on B would be:
break set <HoweverYouSpecifyB> -C "break list BreakpointA" -C "break disable BreakpointA" --one-shot
The break list BreakpointA output will show the hit count of A when you hit B, which is what you wanted to know. By disabling A when you hit B, the hit count for A will stay what it was when you hit B, so you should be able to check it at any point after that (till you rerun).
I like to use named breakpoints when I'm doing a little breakpoint two-step like this, otherwise you have to use the ID of the first breakpoint, and that can change from run to run depending on the order in which you set breakpoints.
I also made breakpoint B a one-shot since you're just using it to freeze the hit-count of A so it only needs to get hit the once. If it's more convenient you could also make B auto continue and then just read out the hit count of A when the program exits.
If you wanted to get fancier, you could use a Python callback for B instead, and get the hit count from A and report that however you want. It's more work but it is easier to control output formatting from Python...
Is there an automatic way to do this?
In GDB, I usually do this:
(gdb) ign 1 10000
(gdb) cont
When the second (B) breakpoint is hit, info break will say something like:
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000555555555129 in a at t.c:1
breakpoint already hit 1234 times <<<===
ignore next 8766 hits
2 breakpoint keep y 0x0000555555555130 in b at t.c:2
breakpoint already hit 1 time
If 10000 turns out to not be enough, you could always increase it to 10000000 instead.
How can I repeatedly run a command in LLDB for debugging C++ code?
For example, when I set a breakpoint inside a loop and want to continue for 10 iterations before stopping, I am currently typing continue ten times manually to do this. Is there a better way?
As an example, let's say I have this code block:
int i = 0;
while (true) {
// Increment i
i++;
}
If I set a breakpoint on the line with the comment, I could keep using the command continue to go through one iteration of the loop and go back to that line. However, if I wanted to skip over 10 iterations (i.e. use the command continue 10 times), how would I do that?
lldb tends to use options where gdb would use a command argument. That makes it easier to have a bunch of different ways to condition a particular command without having to come up with ad hoc mini-syntaxes for each command.
Anyway, so in lldb you would do:
(lldb) c -i 10
You can see this in help:
(lldb) help continue
Continue execution of all threads in the current process.
Syntax: continue <cmd-options>
Command Options Usage:
continue [-i <unsigned-integer>]
-i <unsigned-integer> ( --ignore-count <unsigned-integer> )
Ignore <N> crossings of the breakpoint (if it exists) for the currently selected thread.
'continue' is an abbreviation for 'process continue'
Note also that you can do the same thing just by setting the ignore count in the breakpoint you just hit: break modify -i 10 <BKPTNO>.
Just add a conditional breakpoint. In gdb it's like this
break ... if cond
Set a breakpoint with condition cond; evaluate the expression cond each time the breakpoint is reached, and stop only if the value is nonzero--that is, if cond evaluates as true. `...' stands for one of the possible arguments described above (or no argument) specifying where to break. See section Break conditions, for more information on breakpoint conditions.
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_28.html
For example if i is currently 0 and you want to break on line 10 then use
break 10 if i >= 10
Just increase the condition value based no the current value of i
I don't know lldb but according the the mapping list break foo if strcmp(y,"hello") == 0 in gdb can be done as the following in lldb
(lldb) breakpoint set --name foo --condition '(int)strcmp(y,"hello") == 0'
(lldb) br s -n foo -c '(int)strcmp(y,"hello") == 0'
If there's no loop counter you can just declare a debug variable yourself
expr unsigned int $foo = 1
breakpoint set --name foo --condition '++$foo >= 10'
I need to debug a flow using gdb - I do not know the call stack hence cannot set break points and going thru first entry points will be really very tedious in project code that runs thru thousands of line.
In same regards is there a way that when I start the program execution via gdb we enable some commands (after some initial breakpoint) - hence when the program starts processing further on it print file name line number without user interaction - something like code flow itself?
Well I want to list lines of code when executing via GDB - like we do
when breakpoint is set and we run 'step'.
You can run step in infinite loop like this:
(gdb) start
Temporary breakpoint 2, main () at ttt123.cpp:23
23 vector<A> v1;
(gdb) while 1
>step
>end
Assume the following .gdbinit:
break foobar
ignore 1 1
run
The program is started using gdb --args ./myprogram --argument1 --argument2 etc.
Now, when I start this the first time around all is fine and dandy. However, if I issue a run on the (gdb) prompt in order to restart the program with the last-known command line, the ignore line will simply not take effect.
The reason is of course clear. The first time around I end up with
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000061ea6a in foobar at ../foobar.c:1173
breakpoint already hit 1 time
And any subsequent run starts with whatever value is shown for X in breakpoint already hit X time. Naturally that value will already exceed the limit set by ignore.
How can I reset the stats on the breakpoints or better yet how can I cause run to do that automatically for me?
How can I reset the stats on the breakpoints or better yet how can I cause run to do that automatically for me?
One way to do that is:
# ~/.gdbinit
break foobar
break main
commands 2
silent
ignore 1 1
continue
end
Now, every time you run, you hit silent breakpoint on main, which resets the ignore count on foobar breakpoint and continues.
At the moment I'm using an eclipse-like IDE and the corresponding debug perspective, that most of you are probably familiar with. While debugging code I quite often find myself stepping through many lines of code and observing variables and double checking if everything is as it is supposed to be.
But suppose there is something like this:
1. important line, e.g. generating a new object;
2. another important line, e.g. some tricky class method;
3. for (int i = 0; i < some_limit; ++i)
4. some_array[i]++;
5. more important stuff;
Obviously I'm interested in what happens in lines 1,2 and 5 (I know this is a poor example, but please bear with me for a little while longer) but I don't want to step through all hundreds (or even thousands) of iterations of lines 3/4.
So, finally, my question: Is there some way to step directly over the for-cycle? What I do right now is set a new breakpoint at line 5 and let the program run as soon as I hit line 3 and I believe this is not an optimal solution.
edit: The eclipse implementation of what ks1322 proposed is called "Run to line" and is mapped to ctrl-r
Use until command instead of next.
From gdb documentation:
Continue running until a source line past the current line, in the
current stack frame, is reached. This command is used to avoid single
stepping through a loop more than once.
If you will use until instead of next, gdb will step over loops only once, which almost exactly what you want.