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