I would like to step into the function GDB is currently at, but not into the functions that are called to prepare the parameters for the call.
Is there a single command in gdb that steps over functions like initial_metadata_flags() and directly into SendInitialMetadata?
void StartCallInternal() {
> single_buf.SendInitialMetadata(&context_->send_initial_metadata_,
context_->initial_metadata_flags());
}
If there is, I did not see it mentioned here: https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html
My current workaround is to step, finish, step, finish, until I get to the primary function on that line. But would like something more direct.
There are similar questions asked about Python and Visual Studio, but I haven't found a good answer for gdb.
You can configure functions that you want to skip while stepping:
(gdb) help skip
Ignore a function while stepping.
Usage: skip [FUNCTION-NAME]
skip [FILE-SPEC] [FUNCTION-SPEC]
If no arguments are given, ignore the current function.
FILE-SPEC is one of:
-fi|-file FILE-NAME
-gfi|-gfile GLOB-FILE-PATTERN
FUNCTION-SPEC is one of:
-fu|-function FUNCTION-NAME
-rfu|-rfunction FUNCTION-NAME-REGULAR-EXPRESSION
...
Related
When debugging C/C++ function that with many arguments, and each arguments may still call some functions, people have to repeated typing step and finish, then reach where this function's body part.
e.g. I'm using OpenCV's solvePnP() function, it requires many arguments:
solvePnP(v_point_3d,v_point_2d,K,D,R,T);
Among which, each argument will be converted from cv::Mat to cv::InputArray, thus calling a init() function.
What I expected is, directly go to where solvePnP() implemented, and I'm not interested in each argument type conversion.
Luckily, there is advance command in gdb. Official document is here， writes:
advance location
Continue running the program up to the given location. An argument is required, which should be of one of the forms described in Specify Location. Execution will also stop upon exit from the current stack frame. This command is similar to until, but advance will not skip over recursive function calls, and the target location doesn’t have to be in the same frame as the current one.
This gdb advance command really helps. And what's the equivalent command in LLDB?
I've search in lldb official's gdb => lldb command mapping web page, https://lldb.llvm.org/use/map.html , but not found.
Edit: I forgot to mention, the gdb usage for me is
(gdb) b main
(gdb) r
(gdb) advance solvePnP
Checkout the sif command for lldb. sif means **Step Into Function
Reference: How to step-into outermost function call in the line with LLDB?
To get all the supported commands of LLDB, one should first go into lldb command, then type help, then there will be the explanations for sif:
sif -- Step through the current block, stopping if you step directly into a function whose name matches the TargetFunctionName.
How can we list all the functions being called in an application. I tried using GDB but its backtrace list only upto the main function call.
I need deeper list i.e list of all the functions being called by the main function and the function being called from these called functions and so on.
Is there a way to get this in gdb? Or could you give me suggestions on how to get this?
How can we list all the functions being called in an application
For any realistically sized application, this list will have thousands of entries, which will probably make it useless.
You can find out all functions defined (but not necessarily called) in an application with the nm command, e.g.
nm /path/to/a.out | egrep ' [TW] '
You can also use GDB to set a breakpoint on each function:
(gdb) set logging on # collect trace in gdb.txt
(gdb) set confirm off # you wouldn't want to confirm every one of them
(gdb) rbreak . # set a breakpoint on each function
Once you continue, you'll hit a breakpoint for each function called. Use the disable and continue commands to move forward. I don't believe there is an easy way to automate that, unless you want to use Python scripting.
Already mentioned gprof is another good option.
You want a call graph. The tool that you want to use is not gdb, it's gprof. You compile your program with -pg and then run it. When it runs a file gmon.out will be produced. You then process this file with gprof and enjoy the output.
record function-call-history
https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html
This should be a great hardware accelerated possibility if you are one of the few people (2015) with a CPU that supports Intel Processor Tracing (Intel PT, intel_pt in /proc/cpuinfo).
GDB docs claim that it can produce output like:
(gdb) list 1, 10
1 void foo (void)
2 {
3 }
4
5 void bar (void)
6 {
7 ...
8 foo ();
9 ...
10 }
(gdb) record function-call-history /ilc
1 bar inst 1,4 at foo.c:6,8
2 foo inst 5,10 at foo.c:2,3
3 bar inst 11,13 at foo.c:9,10
Before using it you need to run:
start
record btrace
which is where a non capable CPU fails with:
Target does not support branch tracing.
CPU support is further discussed at: How to run record instruction-history and function-call-history in GDB?
Related threads:
how to trace function call in C?
Is there a compiler feature to inject custom function entry and exit code?
For embedded, you also consider JTAG and supporting hardware like ARM's DSTREAM, but x86 support does not seem very good: debugging x86 kernel using a hardware debugger
This question might need clarification to decide between what are currently 2 answers. Depends on what you need:
1) You need to know how many times each function is being called in straight list/graph format of functions matched with # of calls. This could lead to ambiguous/inconclusive results if your code is not procedural (i.e. functions calling other functions in a branch out structure without ambiguity of what is calling what). This is basic gprof functionality which requires recompilation with -pg flag.
2) You need a list of functions in the order in which they were called, this depends on your program which is the best/feasible option:
a) IF your program runs and terminates without runtime errors you can use gprof for this purpose.
b) ELSE option above using dbg with logging and break points is the left over option that I learned upon reading this.
3) You need to know not only the order but, for example, the function arguments for each call as well. My current work is simulations in physics of particle transport, so this would ABSOLUTELY be useful in tracking down where anomalous results are coming from... i.e. when the arguments getting passed around stop making sense. I imagine one way to do this is would be a variation on what Employed Russian did except using the following:
(gdb) info args
Logging the results of this command with every break point (set at every function call) gives the args of the current function.
With gdb, if you can find the most child function, you can list its all ancestors like this:
gdb <your-binary>
(gdb) b theMostChildFunction ## put breakpoint on the desired function
(gdb) r ## run the program
(gdb) bt ## backtrace starting from the breakpoint
Otherwise, on linux, you can use perf tool to trace programs and their function calls. The advantage of this, it is tracing all processes including child processes and also it shows usage percentages of the functions in the program.
You can install perf like this:
sudo apt install linux-tools-generic
sudo apt install linux-cloud-tools-generic
Before using perf you may also need to remove some kernel restrictions temporarily:
sudo sh -c 'echo 0 >/proc/sys/kernel/kptr_restrict'
sudo sh -c 'echo 0 >/proc/sys/kernel/perf_event_paranoid'
sudo sh -c 'echo 0 >/proc/sys/kernel/yama/ptrace_scope'
After this, you can run your program binary with perf like this:
perf record -g -s -a <your-binary-and-its-flags>
Then either you can look the output on terminal like this:
perf report
or on text file like this:
perf report -i perf.data > output.txt
vim output.txt
when you are recording the function calls with perf also you may want to filter kernel calls with --all-user flag:
perf record -g -s -a --all-user <your-binary-and-its-flags>
For further information you can look here: https://perf.wiki.kernel.org/index.php/Tutorial
I am trying to automate some debug by printing inputs and outputs of a function via GDB, when that function hits. To enable setting breakpoints at these places, I am doing the following.
I am working with templates, and rbreak :. does not hit the breakpoints at the functions in my file. So i extract line numbers of functions from the executable as follows.
With the executable, extract the linenumber of start of a function;
nm a.out | grep "className" | grep "functionName" | grep " t " | addr2line -e a.out -f | grep "cpp" | uniq
-> this outputs the filename:linenumber
add these contents to a .gdb file with a "b prefix"
Query - how can we extract the line number of a end of a function from the executable ?
With this info, I can add it to the GDB script, the final script would
look something like below. this script would be loaded into GDB before
the execution of the program.
b filepath:<startline of function>
commands
print input1 input2 etc
continue
end
b filepath:<endline of function>
commands
print output1 output2 etc
continue
end
It remains to find only the end line of a given function belonging to a class/file, given the executable and start line of the function
I also considered using GDBs finish command but the control is back to the caller already.
it would be easy to have the prints within the called function instead of the caller, so that we can monitor input/outputs of every call of the function.
This will simplify my debug to a large extent.
Any suggestion/comments is highly appreciated.
Thanks a lot in advance !!
First, notice that template functions are not functions, but actually recipes. When you use a template the compiler generates a function from the template.
If you want to use the break command then you need the full function name. For instance, the template below
template <typename T>
inline T doubleInput(const T& x) {
return 2 * x;
}
will become the function doubleInput<int> when you pass an int, doubleInput<double> when you pass a double, etc. You need the whole name including the <type> part to add a breakpoint with the break command and even in that case it will only stop in that particular case of the template.
But the rbreak command does work with templates. If you write in gdb rbreak doubleInput* then a breakpoint will be added in all existing specializations of the template.
See the answer in this question.
I don't know if gdb nowadays has the feature to add a breakpoint in the return of a function, but answers in the nine years old question provide some possibilities, including a custom python command to find and add a breakpoint to the retq instructions or using reverse debugging. I haven't tried these options.
so I know that my current block is between epb and esp
is there a way to print my stack the following way:
lets says that len=ebp-esp
I would like a command on gdb that would look like this
x/lenx $esp
so I'm priting what's on the stack for the current function being executed?
can I do this using display like:
display/lenx $esp ?
is it possible to have a variable that will change each time
Seems display doesn't allow this. So you can define your own command and simply call it when you need to see a function stack:
define display_stack
eval "x /%dbx $esp", $ebp-$esp
end
And then while debugging your program:
(gdb) display_stack
If you need to see your function stack on each step you can 1) define another command nn and use it when you debug your functions 2) use hook for the pseudo-command, ‘stop’ :
define nn
n
display_stack
end
define hook-stop
echo "hook-stop, display_stack:\n"
display_stack
end
Useful links:
http://sourceware.org/gdb/onlinedocs/gdb/Define.html
http://sourceware.org/gdb/onlinedocs/gdb/Output.html#index-eval-1736
http://sourceware.org/gdb/onlinedocs/gdb/Hooks.html
How can we list all the functions being called in an application. I tried using GDB but its backtrace list only upto the main function call.
I need deeper list i.e list of all the functions being called by the main function and the function being called from these called functions and so on.
Is there a way to get this in gdb? Or could you give me suggestions on how to get this?
How can we list all the functions being called in an application
For any realistically sized application, this list will have thousands of entries, which will probably make it useless.
You can find out all functions defined (but not necessarily called) in an application with the nm command, e.g.
nm /path/to/a.out | egrep ' [TW] '
You can also use GDB to set a breakpoint on each function:
(gdb) set logging on # collect trace in gdb.txt
(gdb) set confirm off # you wouldn't want to confirm every one of them
(gdb) rbreak . # set a breakpoint on each function
Once you continue, you'll hit a breakpoint for each function called. Use the disable and continue commands to move forward. I don't believe there is an easy way to automate that, unless you want to use Python scripting.
Already mentioned gprof is another good option.
You want a call graph. The tool that you want to use is not gdb, it's gprof. You compile your program with -pg and then run it. When it runs a file gmon.out will be produced. You then process this file with gprof and enjoy the output.
record function-call-history
https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html
This should be a great hardware accelerated possibility if you are one of the few people (2015) with a CPU that supports Intel Processor Tracing (Intel PT, intel_pt in /proc/cpuinfo).
GDB docs claim that it can produce output like:
(gdb) list 1, 10
1 void foo (void)
2 {
3 }
4
5 void bar (void)
6 {
7 ...
8 foo ();
9 ...
10 }
(gdb) record function-call-history /ilc
1 bar inst 1,4 at foo.c:6,8
2 foo inst 5,10 at foo.c:2,3
3 bar inst 11,13 at foo.c:9,10
Before using it you need to run:
start
record btrace
which is where a non capable CPU fails with:
Target does not support branch tracing.
CPU support is further discussed at: How to run record instruction-history and function-call-history in GDB?
Related threads:
how to trace function call in C?
Is there a compiler feature to inject custom function entry and exit code?
For embedded, you also consider JTAG and supporting hardware like ARM's DSTREAM, but x86 support does not seem very good: debugging x86 kernel using a hardware debugger
This question might need clarification to decide between what are currently 2 answers. Depends on what you need:
1) You need to know how many times each function is being called in straight list/graph format of functions matched with # of calls. This could lead to ambiguous/inconclusive results if your code is not procedural (i.e. functions calling other functions in a branch out structure without ambiguity of what is calling what). This is basic gprof functionality which requires recompilation with -pg flag.
2) You need a list of functions in the order in which they were called, this depends on your program which is the best/feasible option:
a) IF your program runs and terminates without runtime errors you can use gprof for this purpose.
b) ELSE option above using dbg with logging and break points is the left over option that I learned upon reading this.
3) You need to know not only the order but, for example, the function arguments for each call as well. My current work is simulations in physics of particle transport, so this would ABSOLUTELY be useful in tracking down where anomalous results are coming from... i.e. when the arguments getting passed around stop making sense. I imagine one way to do this is would be a variation on what Employed Russian did except using the following:
(gdb) info args
Logging the results of this command with every break point (set at every function call) gives the args of the current function.
With gdb, if you can find the most child function, you can list its all ancestors like this:
gdb <your-binary>
(gdb) b theMostChildFunction ## put breakpoint on the desired function
(gdb) r ## run the program
(gdb) bt ## backtrace starting from the breakpoint
Otherwise, on linux, you can use perf tool to trace programs and their function calls. The advantage of this, it is tracing all processes including child processes and also it shows usage percentages of the functions in the program.
You can install perf like this:
sudo apt install linux-tools-generic
sudo apt install linux-cloud-tools-generic
Before using perf you may also need to remove some kernel restrictions temporarily:
sudo sh -c 'echo 0 >/proc/sys/kernel/kptr_restrict'
sudo sh -c 'echo 0 >/proc/sys/kernel/perf_event_paranoid'
sudo sh -c 'echo 0 >/proc/sys/kernel/yama/ptrace_scope'
After this, you can run your program binary with perf like this:
perf record -g -s -a <your-binary-and-its-flags>
Then either you can look the output on terminal like this:
perf report
or on text file like this:
perf report -i perf.data > output.txt
vim output.txt
when you are recording the function calls with perf also you may want to filter kernel calls with --all-user flag:
perf record -g -s -a --all-user <your-binary-and-its-flags>
For further information you can look here: https://perf.wiki.kernel.org/index.php/Tutorial