By "at runtime" I meant when pike code is compiled, not when the interpreter is compiled. Presumably this would be an option configurable at runtime.
I understand your sentiment in terms of aim, but it's important to remember that just about any means of debugging (from printf to a debugger) is going to alter execution timing in some largely unquantifiable way, so tracking down races and timing related problems will still be subject to variation even if the exact same bytecode is used.
Bill
December 28, 2018 12:13 PM, "Stephen R. van den Berg" srb@cuci.nl wrote:
H. William Welliver III wrote:
- Does optimization hurt the ability to debug?
Breakpoints on constant expressions or on a for loop, as examples, won???t get hit how you might expect them to. Is that okay, or should we explore ways to skip optimization at runtime?
I personally prefer that optimisation levels are decided at compile time only. Debugging an optimised version would imply that:
- Yes, you cannot put breakpoints everywhere (some code has been optimised out),
the debugger should pick the next nearest spot it *can* insert a breakpoint.
- Yes, some variables are inaccessible because they have been optimised out.
- Yes, single stepping can seem somewhat chaotic, because of code reordering.
But that is what I want, because otherwise I cannot debug optimised programs. Sometimes bugs only show up in optimised code. Being able to debug that without altering the runtime behaviour (timingwise or registerwise), would be essential. -- Stephen.