I've checked in Mago Debugger -- a set of libraries and a Visual Studio plug-in for debugging D 2 programs on Windows.

You can find it at:
  http://dsource.org/projects/mago_debugger

Here's a quick set of features:

  * Starting and stopping a debug session
  * Source level step-in, step-over, and step-out
  * Breakpoints by source line
  * Module and thread views
  * Callstack
  * Memory and Register views
  * Locals view
  * Watch views
  * Disassembly

It uses the CodeView debug info that DMD puts in exes, not the PDB format. But, I do want to support PDB format so that you can step into Microsoft C and C++ code from your D code.

It doesn't have a command line interface, but I encourage you to make one that can be included with this project.

Try it out and take a look at the source code. I'd like to hear your feedback and see your bug reports.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sun, 22 Aug 2010 14:16:28 -0500, Aldo Nunez <aldoSkipallthisNunez1@gmail.com> wrote:

> I've checked in Mago Debugger -- a set of libraries and a Visual Studio plug-in for debugging D 2 programs on Windows.
>
> [snip]

Wow! This is actually pretty cool! Before switching to D2, I was a fervent user of ddebug. And although it sometimes works on D2, it's painfully outdated. I really wish that your debugger could become a replacement for it.

Thanks. I'll give it a try and will report whatever interesting stuff I find.


-- 
Yao G.

This is really impressive work.

I gave it a try, compilation worked fine with a few hickups (mainly due to taking some random (almost compatible) stdint.h/inttypes.h and placing it into mago/include, so a few projects needed to have an additional include search path).

Still, I think it is a bit troublesome for people to build MaGo from source if they are not used to work with the Visual Studio Extensibility, so you should consider providing some precompiled binaries.

There is an installation issue with the addin: MagoDELauncher.Addin declares utf-16 encoding, but it looks more like utf-8. Without changing that, Visual Studio 2008 rejects the addin for me.

Integration with Visual D is not working yet. I changed the debugger GUID, it loads the mago debug engine DLLs, but it returns an error. If you can give me a hint where IVsDebugger::LaunchDebugTargets ends up in the engine, I can investigate further...

Trying the Launch addin, the Visual D projects are listed with empty names (I fixed this), but cannot be launched (no OutputGroups from Visual D, I guess I need to fix that, too).

Loading an executable as a project and launching it with the addin works fine, but I had no luck setting breakpoints. Using "asm { int3; }" activates the debugger and shows shows correct source code association. Unfortunately the local variables are listed without name and values, only the icon.

Looking forward to getting these issues resolved,
Rainer


Aldo Nunez wrote:
> I've checked in Mago Debugger -- a set of libraries and a Visual Studio plug-in for debugging D 2 programs on Windows.
> 
> You can find it at:
>   http://dsource.org/projects/mago_debugger
> 
> Here's a quick set of features:
> 
>   * Starting and stopping a debug session
>   * Source level step-in, step-over, and step-out
>   * Breakpoints by source line
>   * Module and thread views
>   * Callstack
>   * Memory and Register views
>   * Locals view
>   * Watch views
>   * Disassembly
> 
> It uses the CodeView debug info that DMD puts in exes, not the PDB format. But, I do want to support PDB format so that you can step into Microsoft C and C++ code from your D code.
> 
> It doesn't have a command line interface, but I encourage you to make one that can be included with this project.
> 
> Try it out and take a look at the source code. I'd like to hear your feedback and see your bug reports.
> 

I attached a log for a debug session of a sample D debuggee. You can use that as a reference for seeing where LaunchDebugTargets is supposed to end up in the debug engine.

With respect to loading an executable as a project and having a few problems... Were you using Windows XP? I saw those things happen on a friend's Windows XP machine and VS 2005. I haven't been able to debug on that machine, and I haven't been able to figure it out by reviewing the code. I run Vista 64-bit.

I'll fix the add-in. That was a blunder from a last minute change in order to check in the code into the dsource depot.

I'll take a look at the VS SDK build dependency. Do you mean including in the Mago tree the needed headers and libraries from the SDK? I'll have to check what the redistribution conditions are. Another thing I need to fix right away are those embarrassing warnings in EED.

Thanks a lot for the feedback and investigating, Rainer.
   Aldo

On Mon, 23 Aug 2010 00:26:12 -0700, Rainer Schuetze <r.sagitario@gmx.de> wrote:
> This is really impressive work.
>
> I gave it a try, compilation worked fine with a few hickups (mainly due to taking some random (almost compatible) stdint.h/inttypes.h and placing it into mago/include, so a few projects needed to have an additional include search path).
>
> Still, I think it is a bit troublesome for people to build MaGo from source if they are not used to work with the Visual Studio Extensibility, so you should consider providing some precompiled binaries.
>
> There is an installation issue with the addin: MagoDELauncher.Addin declares utf-16 encoding, but it looks more like utf-8. Without changing that, Visual Studio 2008 rejects the addin for me.
>
> Integration with Visual D is not working yet. I changed the debugger GUID, it loads the mago debug engine DLLs, but it returns an error. If you can give me a hint where IVsDebugger::LaunchDebugTargets ends up in the engine, I can investigate further...
>
> Trying the Launch addin, the Visual D projects are listed with empty names (I fixed this), but cannot be launched (no OutputGroups from Visual D, I guess I need to fix that, too).
>
> Loading an executable as a project and launching it with the addin works fine, but I had no luck setting breakpoints. Using "asm { int3; }" activates the debugger and shows shows correct source code association. Unfortunately the local variables are listed without name and values, only the icon.
>
> Looking forward to getting these issues resolved,
> Rainer
>
>
> Aldo Nunez wrote:
>> I've checked in Mago Debugger -- a set of libraries and a Visual Studio
>> plug-in for debugging D 2 programs on Windows.
>>  You can find it at:
>>   http://dsource.org/projects/mago_debugger
>>  Here's a quick set of features:
>>    * Starting and stopping a debug session
>>   * Source level step-in, step-over, and step-out
>>   * Breakpoints by source line
>>   * Module and thread views
>>   * Callstack
>>   * Memory and Register views
>>   * Locals view
>>   * Watch views
>>   * Disassembly
>>  It uses the CodeView debug info that DMD puts in exes, not the PDB
>> format. But, I do want to support PDB format so that you can step into
>> Microsoft C and C++ code from your D code.
>>  It doesn't have a command line interface, but I encourage you to make
>> one that can be included with this project.
>>  Try it out and take a look at the source code. I'd like to hear your
>> feedback and see your bug reports.
>>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

> Still, I think it is a bit troublesome for people to build MaGo from source if they are not used to work with the Visual Studio Extensibility, so you should consider providing some precompiled binaries.

votes++;

Aldo Nunez wrote:
> I attached a log for a debug session of a sample D debuggee. You can use that as a reference for seeing where LaunchDebugTargets is supposed to end up in the debug engine.

Thanks. That helped me finding that Visual D used quotes on the executable name. Without these, it now works as running from the Addin.

> 
> With respect to loading an executable as a project and having a few problems... Were you using Windows XP? I saw those things happen on a friend's Windows XP machine and VS 2005. I haven't been able to debug on that machine, and I haven't been able to figure it out by reviewing the code. I run Vista 64-bit.

Yes, I'm using VS2008 on XP/32. I guess Engine::BindPendingBPsToModule would be a good place to start looking why breakpoints are not resolved...

> 
> I'll fix the add-in. That was a blunder from a last minute change in order to check in the code into the dsource depot.
> 
> I'll take a look at the VS SDK build dependency. Do you mean including in the Mago tree the needed headers and libraries from the SDK? I'll have to check what the redistribution conditions are. Another thing I need to fix right away are those embarrassing warnings in EED.
> 

I've added the VS SDK inc/idl directories and boost and cpptest include dirs to the global VC include settings (no problems with these), but didn't want to pollute them more with a directory for just stdint.h and inttypes.h. So I've placed these in MaGo's top-level include. Most projects found them there, but some did not.
I've downloaded stdint.h and inttypes.h from http://msinttypes.googlecode.com/svn/trunk/, but had to remove some "signed" modifier due to different typedefs elsewhere. So I guess you have a different source for these.

Aldo Nunez wrote:
> With respect to loading an executable as a project and having a few problems... Were you using Windows XP? I saw those things happen on a friend's Windows XP machine and VS 2005. I haven't been able to debug on that machine, and I haven't been able to figure it out by reviewing the code. I run Vista 64-bit.

This boiled down to WideCharToMultiByte not accepting flag WC_ERR_INVALID_CHARS on anything below Vista. If I remove this flag, debugging works well.

Not being able to see class and struct members is a bit of a show stopper for now, but I've seen it's rather high on your priority list.

There are a few more quirks, I'll report them on dsource tonight...

Rainer

== Quote from Rainer Schuetze (r.sagitario@gmx.de)'s article
> Aldo Nunez wrote:
> > With respect to loading an executable as a project and having
a few
> > problems... Were you using Windows XP? I saw those things
happen on a
> > friend's Windows XP machine and VS 2005. I haven't been able
to debug on
> > that machine, and I haven't been able to figure it out by
reviewing the
> > code. I run Vista 64-bit.
> This boiled down to WideCharToMultiByte not accepting flag WC_ERR_INVALID_CHARS on anything below Vista. If I remove this
flag,
> debugging works well.
> Not being able to see class and struct members is a bit of a show
> stopper for now, but I've seen it's rather high on your priority
list.
> There are a few more quirks, I'll report them on dsource
tonight...
> Rainer

I'm working on my long term solution to testing on Windows XP: setting up Windows 7 and the Windows XP Virtual PC image that it brings. But thanks for figuring this out. I'll update the code.

Yeah, evaluating an expression like "record.member" isn't enough when you're debugging. You also need to be able to see all the members at once. I want to start working on that this week.

I'll also look into stdint.h and inttypes.h. I got mine from somewhere else. Looking forward to some bug reports:)

> I'm working on my long term solution to testing on Windows XP:
> setting up Windows 7 and the Windows XP Virtual PC image that it
> brings.

You could also use http://www.virtualbox.org/
Nice, slim, heavily under development :)

> You could also use http://www.virtualbox.org/
> Nice, slim, heavily under development :)

Thanks for the link. But the problem is that I don't have a Win XP installation disc to begin with. With 7 you can get an XP image.