original report: http://www.dsource.org/projects/visuald/ticket/132 reported 05/05/12 08:33:33 by Anonymous for version 0.3.31 bug in Debugger While debugging, stepping with F10 (step over) frequently repeats certain lines. Having to press F10 many times to get past a particular line often leads to accidentally skipping over the following line, which may be of interest ;) There are some patterns I notice: * Entering a function almost always requires 2-3 steps. * Declaration of an array requires as many steps are there are elements in the array (initialising?) * Array assignments likewise. * Lines with more complex expressions. * Function calls often take multiple steps to pass. The annoying workaround for array operations is to set a breakpoint on the next line, F5, then un-set it. Expect; F10 should always move to the next line. I suspect this may be a difference between dwarf and pdb that cv2pdb doesn't account for? Note: I'm debugging 64it GDC binaries using the Visual Studio debugger (can't use Mago)
What I'm seeing with DWARF information looks like references to variables often jump back to the variable declaration.
(In reply to Martin Nowak from comment #1) > What I'm seeing with DWARF information looks like references to variables > often jump back to the variable declaration. Do you mean the dmd generated DWARF info? This bug is for GDC compiled stuff run through cv2pdb and then used in the VS debugger. Is it any different in gdb?
I'd point the finger at the tool used to create PDB information from DWARF emitted from GDC. However, especially over the last couple of months at least, there have been a few notable improvements to how data types and modules are represented in DWARF. But I have never had problems stepping through functions in gdb. Certain things that could be of cause (off the top of my head): - Sugary syntax for complex operations. eg: a[] += b[] + c[]; Where the array operation call is an artificial (compiler generated) function with no source/line location. If the artificial attribute isn't reflected in PDB, then you may see the step pointer remain in the same location until the array operation has exited. - invariant() function called before entering body{}. If all DWARF information is stripped from libdruntime, then you may see this as an extra step required to get into a function. However the line information for the invariant call should be the same as the line where the body starts. - Function call has multiple side effects to evaluate before entering. If it's a compiler generated side effect (internal use of creating temporaries) the debugger should just skip over them. If it's user code, stepping through each side effect should be as you'd expect - a().b() -> enter a() then b(); As for Martins comment. I've only seen jumping around in the debugger when you compile with optimisations (delayed initialisation until variable *actually* used, etc).