List of all function calls made in the application

How can we list all the functions called in the application. I tried using GDB, but its backtrace list only before the main function call.

I need a more detailed list i.e. a list of all functions called by the main function and the called function from these called functions, etc.

Is there any way to get this in gdb? Or could you give me suggestions on how to do this?

+17
callstack gprof gdb
Mar 03 2018-12-12T00:
source share
4 answers

How can we list all the functions called in the application

For any application with a realistic size, this list will contain thousands of entries, which is likely to make it useless.

You can find out all the functions defined (but not necessarily called) in the application using the nm command, for example.

 nm /path/to/a.out | egrep ' [TW] ' 

You can also use GDB to set a breakpoint for 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 

As you continue, you will click a breakpoint for each function called. Use the disable and continue commands to move forward. I do not believe that there is an easy way to automate this if you do not want to use Python scripts.

The already mentioned gprof is another good option.

+16
Mar 03 2018-12-12T00:
source share

You need a call schedule. The tool you want to use is not gdb, but gprof . You compile your program with -pg , and then run it. When it runs the gmon.out file, it will be created. Then you process this file with gprof and enjoy the output.

+9
Mar 03 2018-12-12T00:
source share

write function-call-history

https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html

This can be a great hardware accelerated feature if you are one of the few people (2015) with a processor that supports Intel Processor Tracking (Intel PT, intel_pt in /proc/cpuinfo ).

GDB docs claim they can generate output, for example:

 (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 

where processor failure is not possible:

  Target does not support branch tracing. 

CPU support is further discussed in: How to run the history of command entries and the history of function calls in GDB?

Related topics:

  • How to track function call in C?
  • Is there a compiler function for entering custom functions and exiting code?

For the built-in, you also consider JTAG and supporting hardware like ARM DSTREAM , but x86 support doesn’t look very good: debugging the x86 kernel with a hardware debugger

+4
Aug 04 '15 at 16:26
source share

This question may need clarification in order to resolve, meanwhile, what is currently 2 answers. Depends on what you need:

1) You need to know how many times each function is called in the direct list / graphic format of the functions corresponding to # calls. This can lead to mixed / inconclusive results if your code is not procedural (i.e. Functions calling other functions in the branch structure without ambiguity about what causes what). This is the basic gprof function, which requires recompilation with the -pg flag.

2) You need a list of functions in the order in which they were called, it depends on your program, which is the best / executable option: a) If your program starts and exits without runtime errors, you can use gprof for this purpose. b) The ELSE option above using dbg with logging and breakpoints is the option on the left that I learned after reading it.

3) You need to know not only the order, but, for example, the function arguments for each call. My current job is modeling in particle transport physics, so this would be useful for tracking when abnormal results occur ... i.e. When passed arguments cease to make sense. I guess one way to do this would be a variation of what the Russian was doing, other than using the following:

(gdb) info args

Recording the results of this command with each breakpoint (specified during each function call) gives the arguments of the current function.

+1
02 Sep '13 at 18:37
source share



All Articles