Jump to page: 1 2
Thread overview
Using MS Visual Studio to debug D
May 20, 2004
Arcane Jill
May 20, 2004
Regan Heath
May 21, 2004
Arcane Jill
May 21, 2004
Charlie
May 21, 2004
Hauke Duden
May 21, 2004
J Anderson
May 21, 2004
Hauke Duden
May 22, 2004
Charlie
May 22, 2004
Benji Smith
May 22, 2004
Lev Elbert
May 22, 2004
KTC
May 22, 2004
KTC
May 23, 2004
Arcane Jill
May 24, 2004
Regan Heath
May 24, 2004
Regan Heath
May 24, 2004
Arcane Jill
May 20, 2004
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
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
>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
>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
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
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
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 22, 2004
>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 22, 2004
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
> * 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


« First   ‹ Prev
1 2