www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template IDE debugging problem

reply Arcane Jill <Arcane_member pathlink.com> writes:
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
May 30 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
May 30 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
May 30 2004
parent reply Charlie <Charlie_member pathlink.com> writes:
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
May 30 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 01 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"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
Jun 01 2004