www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Mago Debugger

reply "Aldo Nunez" <aldoSkipallthisNunez1 gmail.com> writes:
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/
Aug 22 2010
next sibling parent "Yao G." <nospamyao gmail.com> writes:
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.
Aug 22 2010
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 23 2010
next sibling parent reply "Aldo Nunez" <aldoSkipallthisNunez1 gmail.com> writes:
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/
Aug 23 2010
next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Aug 23 2010
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Aug 24 2010
parent reply Aldo Nunez <aldoSkipallthisnunez1 gmail.com> writes:
== 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:)
Aug 24 2010
parent reply Trass3r <un known.com> writes:
 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 :)
Aug 24 2010
parent reply Aldo Nunez <aldoSkipallthisnunez1 gmail.com> writes:
 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.
Aug 24 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 24 Aug 2010 16:59:40 -0400, Aldo Nunez  
<aldoSkipallthisnunez1 gmail.com> wrote:


 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.


If you have win xp pro install disc (it has to be pro), you can set up xp  
mode with start-menu integration, even without win 7 pro for free (I did  
it on my win 7 home PC).  MS doesn't make it easy though, and you likely  
have to install all the updates to XP once you create your VM.  Avoiding  
that part alone is probably worth the upgrade price for win 7 pro and the  
pre-configured image.

-Steve
Aug 24 2010
prev sibling parent Trass3r <un known.com> writes:
 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++;
Aug 23 2010
prev sibling parent reply Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Hi

Do you plan to support D1  or is this for D2 only ?

cheers
Nick B.

On 23/08/2010 7:16 a.m., 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.
Aug 31 2010
parent "Aldo Nunez" <aldoSkipallthisNunez1 gmail.com> writes:
It's geared to D 2. To target D 1, you would need to make a few changes to  
the expression evaluator.
   Aldo

On Tue, 31 Aug 2010 00:50:28 -0700, Nick B  
<nick_NOSPAM_.barbalich gmail.com> wrote:


 Hi

 Do you plan to support D1  or is this for D2 only ?

 cheers
 Nick B.

 On 23/08/2010 7:16 a.m., 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/
Sep 01 2010