On 10/21/2010 1:10 AM, Artyom wrote:
My experience is that the stack is difficult to follow in debug builds and close to impossible in release builds. Highly optimized code sometimes discards the notion of a stack altogether in certain cases.
I'm curious how you're going to accomplish this feat and make it portable
too?
If you are successful, this would definitely be a valuable tool to have.
Because I'm not trying to reinvent the wheel:
Linux, Solaris and Mac OS X have functions backtrace and backtrace_symbols in libc: See: http://linux.die.net/man/3/backtrace
Windows starting from XP has RtlCaptureBackTrace in kernel32.dll: See http://msdn.microsoft.com/en-us/library/ff552119(VS.85).aspx
So the rest is translate symbols, under Unixes I have dladdr and under Windows dbghelp.
Of course for inlined functions or for functions with omitted frame pointer you'll not see their frame it the trace, but for rest of it, it should work.
Artyom
This functionality would definitely be appreciated. Beware though, that gcc folks made a controversial decision to set "no frame pointer" flag as a default on 64bit POSIX. That also means that backtrace() will be either very inefficient (in my tests it was more than 100x slower than when the frame pointers are included) or unstable. It actually crashes sometimes. That makes backtrace() pretty much useless for the code that was compiled with the default flags. (which is most of the shared system libraries). And even if the user adds (-with-frame-pointer), the start of the trace might be in the system libraries, so to make backtrace() work in that case you have to somehow limit it only to the user's code. Scary. Andy.