https://issues.dlang.org/show_bug.cgi?id=11028
Iain Buclaw <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Iain Buclaw <[email protected]> --- 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). --
