Tuesday, September 7, 2010

CDT-EDC Where is the Exit?

Our team is working on our next generation of C/C++ development tools for Symbian, Carbide 3.0 (C3). These build on the Eclipse Debugger for C/C++ (EDC) that's part of the CDT project. Our test team reported a bug that raises an interesting question for developers: do you want the debugger to show you what's really happening even if it seems a bit confusing?

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?

5 comments:

Heath said...

Give me the exact behavior, but if you detect something funny like this, pop up a disableable dialog explaining what is going on.

Adrian Petrescu said...

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.

Lars Kurth said...

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.

Chris Recoskie said...

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.

pkures said...

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.