Can I trust the call stack if the program was built using O2 optimization ?

[suds1980]

My program was built using setting of O2 optimization. And my
program blocked at some where .So I crashed the program instance .When
I check the crash dump with Windbg .I found a lot of strange call
stacks . For example, from the call stack , function A::A() will call
B::output() ,but that's impossible , because A::A( ) do not call any
function of B in my code .
So I doubt that should I trust the call stack ?
Or is there any solutions to force the compiler to build a right PDB
even with O2 optimization ?

Thank you very much!

[Alex Blekhman]

My program was built using setting of O2 optimization. [...]
So I doubt that should I trust the call stack ?

No, you cannot trust the stack you see if there is /O2
optimization enabled. /O2 implies /Oy and /Oy will interfere with
stack detection in the debugger.

Or is there any solutions to force the compiler to build a
right PDB even with O2 optimization ?

Yes, disable /Oy optimization explicitly. Put /Oy- flag _after_
/O2 in compiler's command line.

HTH
Alex

[Ondrej Spanel]

The PDB is fine, but there are two things which can make the callstack
hard to understand in release builds:

- stack frame optimization (can cause missing or wrong entries on the
callstack)
- identical COMREF section merging (can cause functions to appear like
some other function which has identical binary code)

Cheers
Ondrej

Post by suds1980
My program was built using setting of O2 optimization. And my
program blocked at some where .So I crashed the program instance .When
I check the crash dump with Windbg .I found a lot of strange call
stacks . For example, from the call stack , function A::A() will call
B::output() ,but that's impossible , because A::A( ) do not call any
function of B in my code .
So I doubt that should I trust the call stack ?
Or is there any solutions to force the compiler to build a right PDB
even with O2 optimization ?
Thank you very much!

[Ben Voigt [C++ MVP]]

Post by Ondrej Spanel
The PDB is fine, but there are two things which can make the callstack
- stack frame optimization (can cause missing or wrong entries on the
callstack)

Also inlining can cause a function to directly contain a call to another
function even though the call was indirect in the source code.

Post by Ondrej Spanel
- identical COMREF section merging (can cause functions to appear like
some other function which has identical binary code)
Cheers
Ondrej

[Ondrej Spanel]

Which reminds me there is one more:

- call of a function placed at the end of a function may be replaced by
a JUMP to it under certain conditions (Tail Call Optimization)

Ondrej

Post by Ben Voigt [C++ MVP]

Post by Ondrej Spanel
The PDB is fine, but there are two things which can make the callstack
- stack frame optimization (can cause missing or wrong entries on the
callstack)

Also inlining can cause a function to directly contain a call to another
function even though the call was indirect in the source code.

Post by Ondrej Spanel
- identical COMREF section merging (can cause functions to appear like
some other function which has identical binary code)
Cheers
Ondrej