0

I want the complete stack trace, mainly the list of functions traversed in a normal execution of a binary.

AFAIK, GDB provides the trace only when it hits a break point or in case of a crash.

Chirag Gangdev
  • 137
  • 2
  • 2
  • 6

2 Answers2

3

That is called the call graph.

That would require either:

  • Instrumentation, i.e. adding code into each function to record when entering/leaving it
  • Profiling, i.e. sampling the program's state and recording which functions are detected
  • Emulation, i.e. running the program on a fake/virtual CPU and recording when jumps occur

Of the above, only the first one would provide 100% accuracy, and of course in general its very hard to do since you often use libraries and those wouldn't be instrumented even if you got your own code to be.

The reason this is hard is that the stack frame "history" isn't normally recorded; once the program has stopped running there is no current stack frame to inspect, unlike when breaking in a debugger.

See also this question.

Community
  • 1
  • 1
unwind
  • 391,730
  • 64
  • 469
  • 606
  • That depends on the OS. If the OS provides something like `dtrace`, such tracing is almost trivial to do: https://wikis.oracle.com/display/DTrace/pid+Provider and http://dtrace.org/blogs/brendan/2011/02/09/dtrace-pid-provider/ – Andrew Henle Jul 08 '15 at 11:55
  • @AndrewHenle That is pretty cool, and somewhat magical. It does say that it breaks for inlined functions though, which is one of the things I meant when I said instrumentation is the only 100% solution. – unwind Jul 08 '15 at 12:01
  • Agreed. And I think the poster needs to provide more details. – Andrew Henle Jul 08 '15 at 12:11
0

If your OS provides dtrace, you can use the PID provider:

pid Provider

The pid provider allows for tracing of the entry and return of any function in a user process ...

Community
  • 1
  • 1
Andrew Henle
  • 32,625
  • 3
  • 24
  • 56