www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using MS Visual Studio to debug D

reply Arcane Jill <Arcane_member pathlink.com> writes:
I got this working by accident. I thought I'd share this in case others find it
useful. You can single-step through D object code using MS Visual C++ on Windows
(even though C++ isn't D). You can place breakpoints, view the values of
variables, etc.

All you need to make this work is a simple naming convention. It is essential
that if your project is called Foo then:

(1) the resulting executable is <anywhere>/Foo/Debug/Foo.exe
(2) the source file containing main is in <anywhere>/Foo/anything.d

Now create a new (empty) VC++ console application project called Foo in
directory <anywhere> with no files in it. (This will create a load of MS files
in <anywhere>/Foo). Then, to this project, add the d source file containing
main.

AND THAT'S IT.

You can set a breakpoint in main(), hit go, and there you are! You can even set
breakpoints in unittest and invariants.

You can see local variable values. Dynamic arrays come out as __int32s, but you
can still copy and paste the high half into the memory window to see the array
contents. Combined with knowledge of D's memory model, you can SEE your program
working, step by step.

Beats printf() any day.

Arcane Jill
May 20 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 20 May 2004 11:59:05 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 I got this working by accident. I thought I'd share this in case others 
 find it
 useful. You can single-step through D object code using MS Visual C++ on 
 Windows
 (even though C++ isn't D). You can place breakpoints, view the values of
 variables, etc.

 All you need to make this work is a simple naming convention. It is 
 essential
 that if your project is called Foo then:

 (1) the resulting executable is <anywhere>/Foo/Debug/Foo.exe
 (2) the source file containing main is in <anywhere>/Foo/anything.d

 Now create a new (empty) VC++ console application project called Foo in
 directory <anywhere> with no files in it. (This will create a load of MS 
 files
 in <anywhere>/Foo). Then, to this project, add the d source file 
 containing
 main.

 AND THAT'S IT.

 You can set a breakpoint in main(), hit go, and there you are! You can 
 even set
 breakpoints in unittest and invariants.

 You can see local variable values. Dynamic arrays come out as __int32s, 
 but you
 can still copy and paste the high half into the memory window to see the 
 array
 contents. Combined with knowledge of D's memory model, you can SEE your 
 program
 working, step by step.

 Beats printf() any day.


This doesn't work for me :(

I get "'d:\d\src\test\Debug\test.exe' does not contain any debugging 
information"

I am compiling with DIDE which uses the following command line:

D:\D\dmd\bin\dmd.exe -g -gt -debug -c  -I. -I.. -odD:\D\src\test 
"D:\D\src\test\acrypt.d" "D:\D\src\test\test.d"

I then move the exe and obj files to the debug directory.

Strangely running the command line above myself does not work, and prints 
nothing?

DMD is.. "Digital Mars D Compiler v0.89"
MS VC++ is.. 6.0 with sp5

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 20 2004
next sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
This doesn't work for me :(

I get "'d:\d\src\test\Debug\test.exe' does not contain any debugging 
information"




This doesn't work for me :(


Okay, I'll look into EXACTLY what I'm doing to make things work over the
weekend, and then I'll post some very detailed instructions, which ... at least
you can be assured ... do work for me.

My previous instructions were posted from memory, and so may be slightly wrong
in the detail.

I can tell you that I *have* seen that same error message myself. I don't know
why it happens, by I can clear it by deleting ALL of my object files and the
exe, and then rebuilding all of them. I guess you probably tried that already
though.

Anyway, I'll post accurate details in the next couple of days,
Arcane Jill
May 21 2004
prev sibling next sibling parent reply Charlie <Charlie_member pathlink.com> writes:
This doesn't work for me :(

I get "'d:\d\src\test\Debug\test.exe' does not contain any debugging 
information"

I am compiling with DIDE which uses the following command line:


<shameless plug>
Ill be releasing the D2Debugger shortly, which will integrate into DIDE.  Heres
a quick screenshot : http://www.atari-soldiers.com/didescreenshots.1.html
</shameless plug>


In article <opr8bmlvr55a2sq9 digitalmars.com>, Regan Heath says...

On Thu, 20 May 2004 11:59:05 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 I got this working by accident. I thought I'd share this in case others 
 find it
 useful. You can single-step through D object code using MS Visual C++ on 
 Windows
 (even though C++ isn't D). You can place breakpoints, view the values of
 variables, etc.

 All you need to make this work is a simple naming convention. It is 
 essential
 that if your project is called Foo then:

 (1) the resulting executable is <anywhere>/Foo/Debug/Foo.exe
 (2) the source file containing main is in <anywhere>/Foo/anything.d

 Now create a new (empty) VC++ console application project called Foo in
 directory <anywhere> with no files in it. (This will create a load of MS 
 files
 in <anywhere>/Foo). Then, to this project, add the d source file 
 containing
 main.

 AND THAT'S IT.

 You can set a breakpoint in main(), hit go, and there you are! You can 
 even set
 breakpoints in unittest and invariants.

 You can see local variable values. Dynamic arrays come out as __int32s, 
 but you
 can still copy and paste the high half into the memory window to see the 
 array
 contents. Combined with knowledge of D's memory model, you can SEE your 
 program
 working, step by step.

 Beats printf() any day.


This doesn't work for me :(

I get "'d:\d\src\test\Debug\test.exe' does not contain any debugging 
information"

I am compiling with DIDE which uses the following command line:

D:\D\dmd\bin\dmd.exe -g -gt -debug -c  -I. -I.. -odD:\D\src\test 
"D:\D\src\test\acrypt.d" "D:\D\src\test\test.d"

I then move the exe and obj files to the debug directory.

Strangely running the command line above myself does not work, and prints 
nothing?

DMD is.. "Digital Mars D Compiler v0.89"
MS VC++ is.. 6.0 with sp5

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 21 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Charlie wrote:

 <shameless plug>
 Ill be releasing the D2Debugger shortly, which will integrate into DIDE.  Heres
 a quick screenshot : http://www.atari-soldiers.com/didescreenshots.1.html
 </shameless plug>


<cheers> Finally! I've been missing a good debugger for D. Printf just 
doesn't cut it when you're used to the level of convenience that Visual 
C++ provides ;).

When do you expect to release this?


Hauke
May 21 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Hauke Duden wrote:


 Charlie wrote:


 <shameless plug>
 Ill be releasing the D2Debugger shortly, which will integrate into 
 DIDE.  Heres
 a quick screenshot : 
 http://www.atari-soldiers.com/didescreenshots.1.html
 </shameless plug>



 <cheers> Finally! I've been missing a good debugger for D. Printf just 
 doesn't cut it when you're used to the level of convenience that 
 Visual C++ provides ;).

 When do you expect to release this?


 Hauke


I hate to <unplug> but D2Debugger will be an improved version of dig-dug 
made be Charles.  Dig-dug is at least a step up from printf.  Get 
dig-dug from dsource, then switch over to D2Debugger  when that comes out.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 21 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
J Anderson wrote:

 I hate to <unplug> but D2Debugger will be an improved version of dig-dug 
 made be Charles.  Dig-dug is at least a step up from printf.  Get 
 dig-dug from dsource, then switch over to D2Debugger  when that comes out.
 


Thanks. I didn't realize that digdug is already in a usable state. I'll 
give it a whirl...

Hauke
May 21 2004
prev sibling parent reply Charlie <Charlie_member pathlink.com> writes:
When do you expect to release this?


Soon as I work out a couple of kinks, and figure out how VS and other debuggers
do the variable examining.  I think I almost got it( though im open to ideas! )

It occurs to me that debuggers havent really progessed much over the years.  I
wonder what would make for a really good debugger, above and beyond the whole
step / break .  I rarely use a debugger, ideas ?  Since D is a cut above the
rest, maybe we need a new debugger to go with it.

Charlie


In article <c8l7ud$9n4$1 digitaldaemon.com>, Hauke Duden says...

Charlie wrote:

 <shameless plug>
 Ill be releasing the D2Debugger shortly, which will integrate into DIDE.  Heres
 a quick screenshot : http://www.atari-soldiers.com/didescreenshots.1.html
 </shameless plug>


<cheers> Finally! I've been missing a good debugger for D. Printf just 
doesn't cut it when you're used to the level of convenience that Visual 
C++ provides ;).

When do you expect to release this?


Hauke
May 21 2004
next sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
On Sat, 22 May 2004 01:27:15 +0000 (UTC), Charlie
<Charlie_member pathlink.com> wrote:


It occurs to me that debuggers havent really progessed much over the years.  I
wonder what would make for a really good debugger, above and beyond the whole
step / break .  I rarely use a debugger, ideas ?  Since D is a cut above the
rest, maybe we need a new debugger to go with it.


Some really cool debugger features that I've seen:

* The ability to step forward and _backward_ within code.
* The ability to change the values of runtime variables _during_
program execution.
* The ability to modify the source code _during_ code execution and
step through the new lines of code, without having to restart the
debugging session.

Okay, so admittedly, these are all features that I've seen in Java
debuggers. And maybe it's impossible to implement features like this
in a compiled (non-VM) language. But I think they're pretty cool
features, and that's what you asked about.

So....you'll have those implemented by Monday, right???

--Benji Smith
May 21 2004
parent reply "Lev Elbert" <elbertlev comcast.net> writes:
 * The ability to step forward and _backward_ within code.
 * The ability to change the values of runtime variables _during_
 program execution.
 * The ability to modify the source code _during_ code execution and
 step through the new lines of code, without having to restart the
 debugging session.
 Okay, so admittedly, these are all features that I've seen in Java
 debuggers. And maybe it's impossible to implement features like this
 in a compiled (non-VM) language.


All features mentioned above are implemented in VS C++, BASIC, J++ etc.
Not sure what meand stepping _backward_. But in VS C++ debugger you can set
the NEXT statement (line). So MS did it for non VM languages.


"Benji Smith" <dlanguage xxagg.com> wrote in message
news:u3kta0phu4fbh926kd2lkpbhi15jc4k752 4ax.com...

 On Sat, 22 May 2004 01:27:15 +0000 (UTC), Charlie
 <Charlie_member pathlink.com> wrote:


It occurs to me that debuggers havent really progessed much over the




years.  I

wonder what would make for a really good debugger, above and beyond the




whole

step / break .  I rarely use a debugger, ideas ?  Since D is a cut above




the

rest, maybe we need a new debugger to go with it.


 Some really cool debugger features that I've seen:

 * The ability to step forward and _backward_ within code.
 * The ability to change the values of runtime variables _during_
 program execution.
 * The ability to modify the source code _during_ code execution and
 step through the new lines of code, without having to restart the
 debugging session.

 Okay, so admittedly, these are all features that I've seen in Java
 debuggers. And maybe it's impossible to implement features like this
 in a compiled (non-VM) language. But I think they're pretty cool
 features, and that's what you asked about.

 So....you'll have those implemented by Monday, right???

 --Benji Smith
May 22 2004
parent "KTC" <me here.com> writes:
"Lev Elbert" wrote...

 * The ability to step forward and _backward_ within code.
 * The ability to change the values of runtime variables _during_
 program execution.
 * The ability to modify the source code _during_ code execution and
 step through the new lines of code, without having to restart the
 debugging session.
 Okay, so admittedly, these are all features that I've seen in Java
 debuggers. And maybe it's impossible to implement features like this
 in a compiled (non-VM) language.


 All features mentioned above are implemented in VS C++, BASIC, J++ etc.
 Not sure what meand stepping _backward_. But in VS C++ debugger you can


set

 the NEXT statement (line). So MS did it for non VM languages.


There exist debugger where one can step forward & backward at will for a
java program (reverse execution of code).

See:   http://www.dcs.ed.ac.uk/home/jjc/
(Bdbj section at bottom of page)


KTC
-- 
Experience is a good school but the fees are high.
    - Heinrich Heine
May 22 2004
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Charlie wrote:

When do you expect to release this?


 
 
 Soon as I work out a couple of kinks, and figure out how VS and other debuggers
 do the variable examining.  I think I almost got it( though im open to ideas! )
 
 It occurs to me that debuggers havent really progessed much over the years.  I
 wonder what would make for a really good debugger, above and beyond the whole
 step / break .  I rarely use a debugger, ideas ?  Since D is a cut above the
 rest, maybe we need a new debugger to go with it.



Keyboard shorcuts for everything.


-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---  M V? PS+ PE Y+ PGP t+ 5- X+++  R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------
May 22 2004
prev sibling parent reply "KTC" <me here.com> writes:
"Regan Heath" wrote...

 All you need to make this work is a simple naming convention. It is
 essential that if your project is called Foo then:

 (1) the resulting executable is <anywhere>/Foo/Debug/Foo.exe
 (2) the source file containing main is in <anywhere>/Foo/anything.d

 Now create a new (empty) VC++ console application project called Foo in
 directory <anywhere> with no files in it. (This will create a load of MS
 files in <anywhere>/Foo). Then, to this project, add the d
 source file containing main.





 This doesn't work for me :(


dmd v0.82, MS VC++ .NET 2003 :

New > Win32 Project > console application.
Added test.d source file to project's Source Files.
dmd -g -gt -debug test.d

Works okay for me :-)

KTC
-- 
Experience is a good school but the fees are high.
    - Heinrich Heine
May 22 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
Okay. I got this going over the weekend. It worked first time. Here's what I
did....

*) I created the directory "X:\D\Modules\etc"

*) I created the directory "X:\D\Modules\etc\bigint_test". Note that it was
important NOT to name the directory "bigint" because "bigint" is going to be the
name of a module under etc, and so cannot also be the name of a directory under
etc.

*) In this directory, I created the file "X:\D\Modules\etc\bigint_test\main.d".
It lists as follows:


       import std.c.stdio;

       int main(char[][] args)
       {
          printf("Hello, world\n");
          return 0;
       }


*) I also created the following directories:


       "X:\D\Modules\etc\bigint_test\Debug"
       "X:\D\Modules\etc\bigint_test\Release"


*) I compiled the program. I do have a custom build tool, but nonetheless you
can do this by hand or using a makefile. The commands executed by my build tool
(in the directory: "X:\D\Modules\etc\bigint_test") were as follows:


       C:\dmd\bin\dmd -c .\main.d  -debug -g -inline -unittest -IX:\D\Modules
-od.\Debug
       C:\dmd\bin\dmd -g .\Debug\main.obj   -ofbigint_test.exe
       move bigint_test.exe Debug\bigint_test.exe
       move bigint_test.map Debug\bigint_test.map


Line one compiles. Line two links. The remaining lines put things where I want
them. The build was successful.

*) I launched MS Visual Studio (Microsoft Development Environment 2003, Version
7.1.3088; Microsoft .NET Framework 1.1, Version 1.1.4322; Microsoft Visual C++
NET).

*) I clicked on File > New > Project

*) I created a Win32 Console Project; Name = bigint_test; Location =
X:\D\Modules\etc

*) I clicked on Application Settings > Empty Project (that is, I told it to
create a project with no source files).

*) I clicked on Finish. This created the following files:


       X:\D\Modules\etc\bigint_test\bigint_test.ncb
       X:\D\Modules\etc\bigint_test\bigint_test.sln
       X:\D\Modules\etc\bigint_test\bigint_test.suo
       X:\D\Modules\etc\bigint_test\bigint_test.vcproj


(Note that older versions of MSVC++ will create files with different names
(*.mcp, *.mcw, etc.). I don't know if this matters, but I suspect not)

*) In the "Solution Explorer" pane (called Workspace in older versions) I
right-clicked on my project "bigint_test" and from the context menu, selected
Add > Add Existing Item... I changed the filename filter to All Files, and
clicked on "main.d". This added "main.d" to the project. Note that VC++ does not
consider it a source file, but it's there nonetheless.

*) I double-clicked on "main.d" in the "Solution Explorer" pane. This displayed
the source code in the source code pane. VC++ cannot do syntax highlighting for
D, and so you just get boring black text on a white background. For this reason
I prefer to use a real text editor (TextPad) for writing the code, and VC++ just
for debugging it.

*) I put a breakpoint on the printf line.

*) I clicked on the "go" button.

*) It worked. The program ran, and halted at the breakpoint, with the little
yellow arrow sitting on the breakpoint, and the values of all local variables at
that time displayed in the "Locals" pane.

Note that you do not need to add any other source files to this project - even
if your project contains many source files, and even if you want breakpoints in
those source files. Somehow it just all works by magic.
May 23 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> escribió en el mensaje
news:c8r6rc$2rvv$1 digitaldaemon.com
| Okay. I got this going over the weekend. It worked first time. Here's what
I
| did....
|
| [long snip]
|

Good for you. A couple of things:
a. You can use "dmd .... -ofDebug\bigint_test.exe"
b. In VS, you can go to Project properties and set the exe file to any file
you want, so you don't need to have project\debug and all that.

-----------------------
Carlos Santander Bernal
May 23 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 23 May 2004 21:59:08 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 Okay. I got this going over the weekend. It worked first time. Here's 
 what I did....


Thanks for this, it works now.

The reason it did not work before was the way in which DIDE was compiling 
it, DIDE was not including /CO in the link step. Adding this fixes it. 
(you still have to move the .obj and .exe to the Debug dir)

I just tried to get the MSDEV Custom build option to do all the work for 
me, first I define a custom build for each .d file, using a command line 
like the ones you have below, the output file being the .obj file. This 
works, it compiles all the .d files into .obj files, but, then it tries to 
link it using the MSDEV linker, this fails.

If I can get it to skip the link step...


FYI...

You do not need to move the .map file into the Debug directory. Seems to 
work without it. You can compile the .exe directly into the Debug 
directory with:

C:\dmd\bin\dmd -c .\main.d  -debug -g -inline -unittest -IX:\D\Modules 
-od.\Debug
C:\dmd\bin\dmd -g .\Debug\main.obj   -of.\Debug\bigint_test.exe

(so you do not need to move anything after building with those lines)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 23 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 20 May 2004 11:59:05 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 You can see local variable values. Dynamic arrays come out as __int32s, 
 but you can still copy and paste the high half into the memory window to 
 see the array contents.


Can you show me an example of this.. I'm not sure exactly what you mean, 
for example a char[] call A gets displayed as "35518073867862116", what do 
I copy/paste and what else do I type to get something useful displayed.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 23 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <opr8hm45w75a2sq9 digitalmars.com>, Regan Heath says...

On Thu, 20 May 2004 11:59:05 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:

 You can see local variable values. Dynamic arrays come out as __int32s, 
 but you can still copy and paste the high half into the memory window to 
 see the array contents.


Can you show me an example of this.. I'm not sure exactly what you mean, 
for example a char[] call A gets displayed as "35518073867862116", what do 
I copy/paste and what else do I type to get something useful displayed.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/



Yes, it's easy. In fact, I'll use your own example. First, you have to get your
numbers displayed in hex, not in decimal. In this case 35518073867862116 happens
to be 0x7E2F800000000064. So the high half - 0x7E2F8000 - is the address of the
array in memory, and the low half - 0x00000064 - is the number of elements in
the array.

You can even type an expression like this into the watch window if you really
want to see stuff live:


       (char *)(p >> 8)


..although it's a bit of pain to do this for every variable. Just
copy-and-pasting the "0x" and the first eight hex digits into the memory window
is usually good enough for me.

Arcane Jill
May 24 2004