Hi,

When I use VC++ to single-step through source code, everything is fine until the point of execution reaches a template function.

Stepping into a function in a template causes the debugger to jump to completely the wrong place. No longer does it follow the source code. Instead, it follows a deterministic but unpredictable path through the wrong file.

I have a horrible suspicion that it's at the right line in the wrong file. But I could be wrong.

I tend not to use things I can't debug properly. For me right now, it's easier to avoid templates than to use them. I don't want to have to go back to printf debugging - I need something a bit more fine grained than that ...  which is exactly what I have, if I don't use templates.

The problem has got to be in the debugging information compiled into the .obj.
(At a guess).

Any chance this could be looked into?

Arcane Jill

Arcane Jill wrote:

>Hi,
>
>When I use VC++ to single-step through source code, everything is fine until the
>point of execution reaches a template function.
>
>Stepping into a function in a template causes the debugger to jump to completely
>the wrong place. No longer does it follow the source code. Instead, it follows a
>deterministic but unpredictable path through the wrong file.
>
>I have a horrible suspicion that it's at the right line in the wrong file. But I
>could be wrong.
>
>I tend not to use things I can't debug properly. For me right now, it's easier
>to avoid templates than to use them. I don't want to have to go back to printf
>debugging - I need something a bit more fine grained than that ...  which is
>exactly what I have, if I don't use templates.
>
>The problem has got to be in the debugging information compiled into the .obj.
>(At a guess).
>
>Any chance this could be looked into?
>
>Arcane Jill
>  
>
I don't know if this is related but I reported a problem in compilation line-numbers and sent Walter a problem file.  When a /r is missing sometimes dmd treats that as the same line.  VS does seem to muck up line-numbers like this sometimes.  I only got this problem because I was coping/pasting code from VS into DIDE though.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <c9ctnt$fr$1@digitaldaemon.com>, J Anderson says...

>I don't know if this is related but I reported a problem in compilation line-numbers and sent Walter a problem file.  When a /r is missing sometimes dmd treats that as the same line.  VS does seem to muck up line-numbers like this sometimes.  I only got this problem because I was coping/pasting code from VS into DIDE though.

I don't think it could be that. I use VS *only* for debugging. I write my source code with a plain text file (TextPad) and use it to invoke the dmd compiler directly. (Well, almost directly. There's a tool which decides what to build and what not to build). The point is the VS is not involved in any way in creating either the source files or the .obj files - only in /interpreting/ the obj files which dmd has produced.

Jill

The point is the VS is not involved in any way in creating
>either the source files or the .obj files - only in /interpreting/ the obj files which dmd has produced.


Just a small note, the debugging information is compiled directly into the executable using CodeView version 4 format, Walter has admitted not all of the debugging info gets produced.  Hopefully this will get remedied before 1.0.

In article <c9cup3$2ec$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <c9ctnt$fr$1@digitaldaemon.com>, J Anderson says...
>
>>I don't know if this is related but I reported a problem in compilation line-numbers and sent Walter a problem file.  When a /r is missing sometimes dmd treats that as the same line.  VS does seem to muck up line-numbers like this sometimes.  I only got this problem because I was coping/pasting code from VS into DIDE though.
>
>I don't think it could be that. I use VS *only* for debugging. I write my source code with a plain text file (TextPad) and use it to invoke the dmd compiler directly. (Well, almost directly. There's a tool which decides what to build and what not to build). The point is the VS is not involved in any way in creating either the source files or the .obj files - only in /interpreting/ the obj files which dmd has produced.
>
>Jill
>
>

In article <c9dcv9$lid$1@digitaldaemon.com>, Charlie says...
>
>Just a small note, the debugging information is compiled directly into the executable using CodeView version 4 format, Walter has admitted not all of the debugging info gets produced.  Hopefully this will get remedied before 1.0.

This is really, really important - at least for those of us who like more detailed debugging than a load of printfs scattered throughout the source.

Currently debugging information works for non-template code, but enter a template and it all goes haywire.

Another quirk. Stepping into interface code doesn't work properly. For example:

>001    interface I
>002    {
>003        void f();
>004    }
>005
>006    class A : I
>007    {
>008        void f()
>009        {
>010            // stuff
>011        }
>012    }
>013
>014    void g(I i)
>015    {
>016        f(i);
>017    }

Now, with the cursor on line 016, "Step into" steps right OVER the call to f(i), not into it. However, there is a workaround - you have to set a breakpoint on line 010.

This is only a mildly irritating quirk (since I have a workaround), but I have no workaround for the template problem.

Any chance fixing this could be given a reasonably high priority?

Arcane Jill

"Arcane Jill"  wrote
> This is really, really important - at least for those of us who like more detailed debugging than a load of printfs scattered throughout the source.

It's been a very long time since D'ebugger support provided the bare essentials, yet nothing obvious has happened since. Whilst not wishing to complain too loudly, I think the more Walter hears about fully populated debug symbols the better off we'll all be (it has been said many time in the past). Otherwise we may end up with a v1.0 sans class/struct member inspection.

- Kris