Debugging of optimized code

urs@engineering.ucsb.edu (Urs Hoelzle) writes:


> Of course, deoptimization is no panacea. For example, it relies on
> the compiler being correct, it can't hide all optimizations, and it
> probably doesn't work as well for non-pointer-safe languages because
> every memory access can potentially fail. I just wanted to observe
> that the situation isn't hopeless, and I think today's debuggers could
> still be improved quite a bit. For example, there's no fundamental
> reason why you shouldn't be able to set a breakpoint in a method even
> if that method was inlined in many places.




You are right. The two biggest advantages that we have experienced
from debugging optimized code are:


- Just because code produces the correct answers with no optimization.
It does not follow that the code is correct. With optimizations on,
certain bugs materialize, and they are not always compiler related.


- When your products ships, it is going to be optimized. You need
that ability to debug core dumps in the field.


Thank you.


Steve Simmons
--

Return to the comp.compilers page.
Search the comp.compilers archives again.