The most helpful thing the debugger can do is display the
stack trace. You can see them using gdb's
backtrace command, shortened to "bt", or its wonderful synonym,
"where".
Every time a function gets called, a new
stack frame is created, and the calling one gets saved. It contains saved values, such as variables and instruction pointers, so that when the called function returns, the calling one picks up where it left off.
The top of the stack trace is the most recent function called -- it will be frame number 0. And all of the other calls to that point will be in the trace. You don't need to know much about programming to use it to see what functions call what, and the code paths taken by the program. The gdb
frame command will let you inspect any of them for variable values, too. And you can go up and down through the frames with the
up and
down commands.
Your loop will either be looping through multiple functions, or stuck inside a single function. Either way, you should be able to watch it progress. The gdb() "step" command will move a program one line at a time through a program, including any called functions, while the "next" command will treat a function call as if it is a single instruction. Both may be helpful.
See
this recent rant from a non-programmer who increased the security of an unreadable, confusing application, primarily by using stack traces from core files.
