During many, sometimes inundating, debugging sessions using DDD, I stumble upon loops. And I keep pressing next to get past it, and if there are many iterations, I just set a break point right after it, and press "continue." Is there any other way to go past loops?
You want the "until" command - see the gdb manual at http://www.gnu.org/software/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. It is
like the next command, except that
when until encounters a jump, it
automatically continues execution
until the program counter is greater
than the address of the jump.
This means that when you reach the end
of a loop after single stepping though
it, until makes your program continue
execution until it exits the loop. In
contrast, a next command at the end of
a loop simply steps back to the
beginning of the loop, which forces
you to step through the next
iteration.
I typically use the "continue until here" which sets a temporary breakpoint at that location and immediately continues execution. It is accessed via mouse button 3 which opens a popup menu.
Related
I know how to create/modify a breakpoint to stop only on a specific thread using breakpoint modify <breakpoint-id> -T <thread-name>, but can I do it the other way around, preventing the breakpoint to stop on a specific thread?
I have a log thread that use the same function I'm trying to debug on other threads and it's annoying to have to let it continue every time it hits.
You can do this sort of thing using the lldb Python API and Python breakpoint callbacks. The callback returns a "should stop" value, i.e. if it returns True, you stop at the breakpoint, and False you continue.
So for instance:
(lldb) breakpoint command add -s python -o 'return frame.thread.name != "MyThread"'
is what you wanted. Note, in this example, I didn't provide a breakpoint ID. In lldb that means "act on the last set breakpoint". But you can also supply the breakpoint ID if the one you want to add the command to doesn't happen to be the last breakpoint you set. And if you want to add it to multiple breakpoints, you can specify a breakpoint ID list.
There's more on the API's and the callback format here:
https://lldb.llvm.org/python_api.html
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
Note, however, that breakpoints with should-stop callbacks will force a stop every time the breakpoint is hit. lldb auto-continues pretty quickly, so for many applications this isn't a problem. But just getting from the stop over to the debugger and back is not cheap, so if your breakpoint is in a work loop and getting hit hundreds of thousands of times a second, this is going to slow down the run. If that ends up being a problem and you control your source code, tricks like the one Eljay suggested in the comments can be really handy.
I am running a fortran code. The code has no pauses nor any switches that ask user to do anything. It should run beginning to end with no stops. This is a code that has a big outer loop and several OpenMP inner loops. The only thing I output are the index of the bigger outer loop so that I can know where the code is.
The code usually runs with no problems. However, the last two times I run it, the code stopped with no error (I know that because the cores usage started being 0%). However if I press enter in the console the code resumes normally.
So my question, is there any way to pause a fortran code at run time without having an explicit pause on the code?
Do you have any READ statements in your program? They'd pause the terminal if they're waiting for input.
For example, the following program looks like it's pausing in the middle of the loop. Pressing enter allows it to continue.
integer i
do i = 1, 10
if (i == 5) read(*, *)
print *, i
end do
end
Perhaps you or someone else added a READ for debugging purposes and forgot to remove it?
How are SW breakpoints handled (conceptually) by gdb stub or server (I assume client stub and server handle them in pretty much same way)?
I'm interested in a 'bare metal' target where the gdb stub/server runs, and both breakpoints and single stepping use software interrupts.
My actual questions:
When a breakpoint is hit, how is the stored instruction run so that the breakpoint can be 're-installed' and the (saved) machine status (including register contents) is not changed from the moment of hitting the breakpoint?
=>When is the breakpoint re-installed and how? Between breakpoint hit and entering the command interpreter, or during the next single step or coninue?
Also how does single-stepping over breakpoint work such that the original non-breakpoint instruction gets executed, and the breakpoint still remains there after being single-stepped over?
[edit]
Forgot: the document "GDB Internals" seems to be missing that info - and actually the whole subchapter about single stepping in the "Algorithms" chapter.
[edit2]
Ah, I seem to need stronger glasses: The 'Internals'-manual says:
"When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on."
The single stepping over breakpoint, however, is still open question.
The single stepping over breakpoint, however, is still open question.
It's done exactly the same way as continue, except for the last step ("and continue on"). That is:
Process stops. GDB "looks around", discovers that $ip points to one of its breakpoints.
User issues continue, next, step or stepi command.
Restore original instruction (i.e. remove the breakpoint)
Single-step process
Re-insert breakpoint
Continue (this is done for continue but not for next, step or stepi).
For stepi, return control to the user (we are already at the next instruction due to step 4 above). For next, continue single-stepping until we reach a line in source that is not the same line we were on at step 1 above.
I'm using gdb to solve a binary bomb as part of a class. Every time we set the bomb off we lose points. I already have a break point on the function that explodes the bomb, but have accidentally stepped past it a couple times already and exploded the bomb. Is there a way to make gdb exit at a specific point rather than just break?
You can attach commands to breakpoints. After you set breakpoint, e.g. #1, do this:
commands 1
quit
end
When debugging an unfamiliar program with gdb, the program often unexpectedly exits after executing next. When that happens I'll typically set a break point, re-run the program and execute step instead of next to trace what's happening. However, sometimes it is difficult to know where to set the break point. Is there a technique set the break automatically? Something like:
define hook-next
break
end
define hookpost-next
# delete the previous break if the program is still running
end
I think you could do it with a combination of hook-next, convenience variables, and a breakpoint on exit. Something like:
define hook-next
set $saved_pc = $pc
end
break exit
commands
break *$saved_pc
end
You may prefer "tbreak" there.