调试优化代码有哪些陷阱？

Question

This question is a follow up of this one where the consensus was that the value of *this* pointer is not correct because of optimization but what does not correct means?

1. That we can't trust the value of this pointer so we should throw it out all together when we debug a release build?
2. That this pointer may change its value as we debug a release build and that's okay because its optimized code, it may not mean any harm?
3. this pointer still points to a valid memory block of the object and the fact it changes is cause of concern even when its optimized code.
4. There is mismatch between the actual code and the optimized generated code, this is why the debugger may show incorrect values or values of variables may change abruptly? I could understand if debugger shows incorrect values but why should these values change?

How do we debug optimized code? A lof of times for exmaple with WinDbg we peek into pointers, objects layouts, stack pointers even instruction pointers..does it mean we can't rely on these values because it's an optimized code? What can we rely on and what not?

Answer 1

IIRC, in VC++ this is passed to functions as register ECX , so the debugger just assumes that ECX is this , just a cast away. That is this is the same as (CADOCommand*)ECX .

In debug builds that is fine because registers are not reused, but in release builds ECX is reused as any other register. Thus the debugger loses track of the actual this or anything pointed to by it. The code will still be correct, of course, only the debugger is affected.

Actually ECX must be overwritten each time a member function of other class is called. For example:

m_pCommand.CreateInstance(__uuidof(Command));

Will be compiled to something like:

PUSH ECX ; push this into the stack
MOV ECX, &m_pCommand
PUSH __uuidof(command) ; a constant maybe?
CALL CCommand::CreateInstance
POP ECX  ; restore this

Note how, if the compiler determines that the current this is no longer needed, then it may omit the PUSH/POP ECX .