https://issues.dlang.org/show_bug.cgi?id=11028

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
What I'm seeing with DWARF information looks like references to variables often jump back to the variable declaration.

--

https://issues.dlang.org/show_bug.cgi?id=11028

--- Comment #2 from Rainer Schuetze <r.sagitario@gmx.de> ---
(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?

--

https://issues.dlang.org/show_bug.cgi?id=11028

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
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).

--

https://issues.dlang.org/show_bug.cgi?id=11028

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--

https://issues.dlang.org/show_bug.cgi?id=11028

Manu <turkeyman@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |turkeyman@gmail.com
         Resolution|---                         |WONTFIX

--