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

Question

这个问题是this的后续问题，其中一致意见是the value of *this* pointer is not correct because of optimization但not correct的含义是什么？

1. 我们不能信任这个指针的值，所以我们应该在调试版本构建时将它们全部抛弃？
2. 当我们调试发布版本时，这个指针可能会改变它的值，并且因为它的优化代码没问题，这可能不会造成任何伤害吗？
3. 此指针仍然指向对象的有效内存块，即使其优化的代码，它也会引起关注。
4. 实际代码与优化生成代码之间存在不匹配，这就是调试器可能显示错误值或变量值可能突然改变的原因？我可以理解调试器是否显示不正确的值，但为什么这些值会发生变化？

我们如何调试优化代码？我们可以看到指针，对象布局，堆栈指针甚至是指令指针等等。例如，它意味着我们不能依赖这些值，因为它是一个优化的代码？ 我们可以依靠什么而不是什么？

Answer 1

IIRC，在VC ++中this作为寄存器ECX传递给函数，因此调试器只假设ECX 是 this，只是抛弃了。这是this与(CADOCommand*)ECX相同。

在调试版本中，因为寄存器不会被重用，所以很好，但在版本构建ECX中可以像其他任何寄存器一样重复使用。因此，调试器会丢失实际this或其指向的任何内容。代码仍然是正确的，当然，只有调试器受到影响。

每次调用其他类的成员函数时，实际上必须覆盖ECX。例如：

m_pCommand.CreateInstance(__uuidof(Command));

将编译为：

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

请注意，如果编译器确定不再需要当前this，那么它可能会省略PUSH/POP ECX。