Here is the situation: you are debugging a C++ function that looks something like this:
Say you are stepping through this function in the debugger and you start at line 31. "value" happens to be 200 so the condition on line 31 fails. You step over and end up on line 36. Step over again to go to line 37. So far everything looks OK. Now you step again from line 37 and you might reasonably expect to exit the function. Instead you end up on line 34! This looks like a heinous bug but is a case of the compiler reorganizing things even in a normal debug build with optimizations off.
The compiler has built this function by putting all of the return/exit code in one place, in the middle of the function at line 34. At the end of the function, at line 37, instead of generating the exit stuff again it simply jumps to the address at line 34 and exits there. It dutifully and accurately records this bit of slight-of-hand into the symbol information and the EDC debugger shows you on line 34.
Should the EDC debugger try to detect this just to avoid confusion? Another perspective is that the debugger should show you exactly what's happening even if the result is sometimes puzzling. What do you think the EDC debugger should do?
6 comments:
Give me the exact behavior, but if you detect something funny like this, pop up a disableable dialog explaining what is going on.
In this situation, I think it's perfectly justified to have a configuration option in the Debugger preferences. One simple binary checkbox adds a whole lot of value here.
I like the idea of a hint which explains what is going on, but to stick to the right behaviour. At the end of the day, this is probably just one case where the debugger behaves unexpectedly because of compiler optimization. The question is how many of these cases can you actually detect reliably. Adrian's suggestion is workable if you can guarantee that you can identify all instances of odd behaviour. A hint is better if you need to work with heuristics which don't always hold.
Really the problem is that the compiler isn't doing what it's been told. No optimization should mean... NO OPTIMIZATION! I'd be filing a bug against the compiler.
I have no problem with the described behavior.You can always switch to Disassembly view if you are confused by it :-) I've seen worse :-) For sure it's a bug in a compiler (gcc?), but I doubt that it will be changed/fixed.
Thanks for your ideas. You can also find the details on Affity Solutions, at the C Developers. The main object of the Affity Solutions is to provide quality web services and is among the few software development company in Nagpur.
Post a Comment