I am new to GDB, using to debug an issue with my program(C++). I used gdb to find the backtrace and then print frames information. During one of the print, let's say the command is something like:
1) frame 2
2) print *this
In between the output of the print call, I am getting the following line:
---Type <return> to continue, or q <return> to quit---
Is this expected from the gdb? We should just continue on that message or it means something?
Note: I didn't set any breakpoint or anything, so didn't expect any message.
When there is too much to print to fit inside the current buffer, gdb will pause after it's hit the limit. If you press enter, it'll continue printing.
I assume this points to an object that has a lot of "stuff" in it, so it's perfectly normal that you get this message. Just keep pressing return until you see the information you're looking for or until there is nothing more to print!
(In other words, there is no breakpoint or anything of the sort getting triggered here and nothing happens to the control flow of the debugged program.)
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.
Is there a way to attach a print statement to the call of a function? I would like to debug a x64 program with nested loops and logic and it would be faster to see the sequence of function calls by printing them as they occur, rather than setting breakpoints.
Can this be done with a post hook in gdb or a different technique?
Is there a way to attach a print statement to the call of a function?
Yes: attach a breakpoint to every function you want to trace, and attach commands to each of these breakpoints:
(gdb) break foo
(gdb) commands $bpnum
continue
end
Now every time foo is called, GDB will print the usual "Breakpoint N ..." message, and then continue.
Obviously you could print additional info (argument values, call stack, thread-id, etc.).
You will probably want to set height 0 to disable pagination. You will also probably want to log this to a file (see set logging file, set logging on, etc.)
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.
My C++ application is giving me some strange output but it runs to completion, I'd like to examine the stack trace but since it isn't segfaulting it is harder to pinpoint where it is. I've tried setting break points on exit, _exit, and abort, but when I call the stack I get something like this
#0 0x00002aaaab1a7620 in exit () from /lib64/libc.so.6
#1 0x000000000041f19e in main ()
This is probably because my application has a perl front end wrapped with sig, is there another way to generate a stack upon completion?
That's what the stack trace should look like. main calls exit at the end and you print the stack trace inside exit. You cannot find where something happens with a stack trace. Once you find where something happens, you can get the stack trace there and find out how the execution got there.
Whatever output you're looking for happened before exit and that function has already returned by the time you get the stack trace. So, you need to put your break point before the output happens. Then you can go over the code line by line to find out which line does the output.
did you build it in debug?
add a breakpoint with "b function_name"
press c to continue
type bt to print the backtrace
I am using GDB to understand a C++ program. I put a break in the middle of the running which turns to be something like:
break main.cpp:500
and I would like to see which functions have been called before. I tried "backtrace" but it shows only info about main, as previous calls to previous functions have already finished.
My question is how can I get (with GDB or another method) the info about which functions have been called before this point, even if the call has been returned.
Thanks
A gdb script might be a solution for your problem.
Create a script that puts break point to each possibly called function.
At break prints the stack with 'bt' and continue the execution.
You should put an other break point to main.cpp:500 to quit from debugging.
b 'main.cpp::500'
commands 1
detach
quit
end
break 'A::f1()'
break 'A::f2()'
while true
continue
bt
end
You can start the script like this:
gdb --command ./gdbscript.gdb fpmanager
If you have too much possibly called function you can grep the code to find all.