It still needs work , right now just run it on a faulty program to see a call stack dump.

http://www.thecodebase.com/DMDebugApi.zip

DMDebugApi\DMDebugLib.dsw is the workspace.

Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
working ).

Eric I know you've been researching dynamic libs / OMF / COFF etc, would you have time to work on this ?  If so maybe we can move discussion to DSP forums.

Charlie

"Charles" <noone@nowhere.com> wrote in message news:ddsufj$atb$1@digitaldaemon.com...
> I have been working on a Debugger for months , but have been strapped for time lately ( like all of us. ).  It uses dbghelp & imghelp to extract symbols.  What its missing is the ability to get 'type' info from
variables
> so it can 'see' their contents , however Walter  said he'd totally add
this
> into the debug info , soon as their codes are figured out.
>
> What I have now is really rough , its a mess in fact . I will clean it up today and put it on the web, but I want to post while everyone is still interested.
>
> Maybe if we all combine what little time we have we can finish it and get
a
> debugger !
>
>
> Charlie
>
>
> "pragma" <pragma_member@pathlink.com> wrote in message news:ddsrcu$7f9$1@digitaldaemon.com...
> > In article <ddsm6e$21n$1@digitaldaemon.com>, Ben Hinkle says...
> > >
> > >> I've received substantial benefits from:
> > >> - Python's dumping of the entire stack trace for uncaught exceptions.
> This
> > >> really helps diagnosis.
> > >
> > >Someone started working on this but I don't know the current status: http://www.digitalmars.com/d/archives/digitalmars/D/22562.html http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
> > >
> > >
> >
> > Did he ever post anything (a zip, URL, anything) to the DNG for his
work?
> Maybe
> > someone should hunt down his email?
> >
> > - EricAnderton at yahoo
>
>

Sorry to flood , I would really like help on this if anyone is willing.  I think having a fully functional debugger would do alot for the language.

Charlie


"Charles" <noone@nowhere.com> wrote in message news:ddt9us$nne$1@digitaldaemon.com...
> It still needs work , right now just run it on a faulty program to see a call stack dump.
>
> http://www.thecodebase.com/DMDebugApi.zip
>
> DMDebugApi\DMDebugLib.dsw is the workspace.
>
> Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
> working ).
>
> Eric I know you've been researching dynamic libs / OMF / COFF etc, would
you
> have time to work on this ?  If so maybe we can move discussion to DSP forums.
>
> Charlie
>
> "Charles" <noone@nowhere.com> wrote in message news:ddsufj$atb$1@digitaldaemon.com...
> > I have been working on a Debugger for months , but have been strapped
for
> > time lately ( like all of us. ).  It uses dbghelp & imghelp to extract symbols.  What its missing is the ability to get 'type' info from
> variables
> > so it can 'see' their contents , however Walter  said he'd totally add
> this
> > into the debug info , soon as their codes are figured out.
> >
> > What I have now is really rough , its a mess in fact . I will clean it
up
> > today and put it on the web, but I want to post while everyone is still interested.
> >
> > Maybe if we all combine what little time we have we can finish it and
get
> a
> > debugger !
> >
> >
> > Charlie
> >
> >
> > "pragma" <pragma_member@pathlink.com> wrote in message news:ddsrcu$7f9$1@digitaldaemon.com...
> > > In article <ddsm6e$21n$1@digitaldaemon.com>, Ben Hinkle says...
> > > >
> > > >> I've received substantial benefits from:
> > > >> - Python's dumping of the entire stack trace for uncaught
exceptions.
> > This
> > > >> really helps diagnosis.
> > > >
> > > >Someone started working on this but I don't know the current status: http://www.digitalmars.com/d/archives/digitalmars/D/22562.html http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
> > > >
> > > >
> > >
> > > Did he ever post anything (a zip, URL, anything) to the DNG for his
> work?
> > Maybe
> > > someone should hunt down his email?
> > >
> > > - EricAnderton at yahoo
> >
> >
>
>

I haven't tried your app but I'm wondering what exactly the debugger has to do with dumping a stack trace on an uncaught exception. I had the impression the stack would be printed by the program as it exists even when there isn't a debugger controlling things. Similarly ordinary D code can request a stack dump or get the stack from an exception.

"Charles" <noone@nowhere.com> wrote in message news:ddtj8s$11bo$1@digitaldaemon.com...
> Sorry to flood , I would really like help on this if anyone is willing.  I think having a fully functional debugger would do alot for the language.
>
> Charlie
>
>
> "Charles" <noone@nowhere.com> wrote in message news:ddt9us$nne$1@digitaldaemon.com...
>> It still needs work , right now just run it on a faulty program to see a call stack dump.
>>
>> http://www.thecodebase.com/DMDebugApi.zip
>>
>> DMDebugApi\DMDebugLib.dsw is the workspace.
>>
>> Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
>> working ).
>>
>> Eric I know you've been researching dynamic libs / OMF / COFF etc, would
> you
>> have time to work on this ?  If so maybe we can move discussion to DSP forums.
>>
>> Charlie
>>
>> "Charles" <noone@nowhere.com> wrote in message news:ddsufj$atb$1@digitaldaemon.com...
>> > I have been working on a Debugger for months , but have been strapped
> for
>> > time lately ( like all of us. ).  It uses dbghelp & imghelp to extract symbols.  What its missing is the ability to get 'type' info from
>> variables
>> > so it can 'see' their contents , however Walter  said he'd totally add
>> this
>> > into the debug info , soon as their codes are figured out.
>> >
>> > What I have now is really rough , its a mess in fact . I will clean it
> up
>> > today and put it on the web, but I want to post while everyone is still interested.
>> >
>> > Maybe if we all combine what little time we have we can finish it and
> get
>> a
>> > debugger !
>> >
>> >
>> > Charlie
>> >
>> >
>> > "pragma" <pragma_member@pathlink.com> wrote in message news:ddsrcu$7f9$1@digitaldaemon.com...
>> > > In article <ddsm6e$21n$1@digitaldaemon.com>, Ben Hinkle says...
>> > > >
>> > > >> I've received substantial benefits from:
>> > > >> - Python's dumping of the entire stack trace for uncaught
> exceptions.
>> > This
>> > > >> really helps diagnosis.
>> > > >
>> > > >Someone started working on this but I don't know the current status: http://www.digitalmars.com/d/archives/digitalmars/D/22562.html http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
>> > > >
>> > > >
>> > >
>> > > Did he ever post anything (a zip, URL, anything) to the DNG for his
>> work?
>> > Maybe
>> > > someone should hunt down his email?
>> > >
>> > > - EricAnderton at yahoo
>> >
>> >
>>
>>
>
> 

> I haven't tried your app but I'm wondering what exactly the debugger has
to
> do with dumping a stack trace on an uncaught exception. I had the
impression
> the stack would be printed by the program as it exists even when there
isn't
> a debugger controlling things.

Its certainly possible , my limited use of debuggers usually is just 'bt' in GDB and using MSVC's 'Call Stack' window , this is the backtrace Im talking about.  At the same point its also possible to enumerate through local variables and display their variables etc.. , thats what Im trying to implement -- it actually shoudln't take that much , just a good chunk of time.

Charlie


"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ddtkhh$12gl$1@digitaldaemon.com...
> I haven't tried your app but I'm wondering what exactly the debugger has
to
> do with dumping a stack trace on an uncaught exception. I had the
impression
> the stack would be printed by the program as it exists even when there
isn't
> a debugger controlling things. Similarly ordinary D code can request a
stack
> dump or get the stack from an exception.
>
> "Charles" <noone@nowhere.com> wrote in message news:ddtj8s$11bo$1@digitaldaemon.com...
> > Sorry to flood , I would really like help on this if anyone is willing.
I
> > think having a fully functional debugger would do alot for the language.
> >
> > Charlie
> >
> >
> > "Charles" <noone@nowhere.com> wrote in message news:ddt9us$nne$1@digitaldaemon.com...
> >> It still needs work , right now just run it on a faulty program to see
a
> >> call stack dump.
> >>
> >> http://www.thecodebase.com/DMDebugApi.zip
> >>
> >> DMDebugApi\DMDebugLib.dsw is the workspace.
> >>
> >> Youll need latest windows SDK , and MSVC6 ( or 7 if you can get it
> >> working ).
> >>
> >> Eric I know you've been researching dynamic libs / OMF / COFF etc,
would
> > you
> >> have time to work on this ?  If so maybe we can move discussion to DSP forums.
> >>
> >> Charlie
> >>
> >> "Charles" <noone@nowhere.com> wrote in message news:ddsufj$atb$1@digitaldaemon.com...
> >> > I have been working on a Debugger for months , but have been strapped
> > for
> >> > time lately ( like all of us. ).  It uses dbghelp & imghelp to
extract
> >> > symbols.  What its missing is the ability to get 'type' info from
> >> variables
> >> > so it can 'see' their contents , however Walter  said he'd totally
add
> >> this
> >> > into the debug info , soon as their codes are figured out.
> >> >
> >> > What I have now is really rough , its a mess in fact . I will clean
it
> > up
> >> > today and put it on the web, but I want to post while everyone is
still
> >> > interested.
> >> >
> >> > Maybe if we all combine what little time we have we can finish it and
> > get
> >> a
> >> > debugger !
> >> >
> >> >
> >> > Charlie
> >> >
> >> >
> >> > "pragma" <pragma_member@pathlink.com> wrote in message news:ddsrcu$7f9$1@digitaldaemon.com...
> >> > > In article <ddsm6e$21n$1@digitaldaemon.com>, Ben Hinkle says...
> >> > > >
> >> > > >> I've received substantial benefits from:
> >> > > >> - Python's dumping of the entire stack trace for uncaught
> > exceptions.
> >> > This
> >> > > >> really helps diagnosis.
> >> > > >
> >> > > >Someone started working on this but I don't know the current
status:
> >> > > >http://www.digitalmars.com/d/archives/digitalmars/D/22562.html http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
> >> > > >
> >> > > >
> >> > >
> >> > > Did he ever post anything (a zip, URL, anything) to the DNG for his
> >> work?
> >> > Maybe
> >> > > someone should hunt down his email?
> >> > >
> >> > > - EricAnderton at yahoo
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Hi,

>I haven't tried your app but I'm wondering what exactly the debugger has to do with dumping a stack trace on an uncaught exception. I had the impression the stack would be printed by the program as it exists even when there isn't a debugger controlling things. Similarly ordinary D code can request a stack dump or get the stack from an exception.

Hm... interesting. I didn't know this could be done. Is there a page on how to do this or maybe some example code?

Thanks!
--AJG.

"AJG" <AJG_member@pathlink.com> wrote in message news:ddu16l$1dus$1@digitaldaemon.com...
> Hi,
>
>>I haven't tried your app but I'm wondering what exactly the debugger has
>>to
>>do with dumping a stack trace on an uncaught exception. I had the
>>impression
>>the stack would be printed by the program as it exists even when there
>>isn't
>>a debugger controlling things. Similarly ordinary D code can request a
>>stack
>>dump or get the stack from an exception.
>
> Hm... interesting. I didn't know this could be done. Is there a page on
> how to
> do this or maybe some example code?
>
> Thanks!
> --AJG.

It's not in D yet (that's what the OP was requesting and it's what Maxime
was working on). The links I posted in my first reply to this thread
http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
are the only clues I know about for getting it implemented. I haven't
checked some of the other replys on this thread for more details. That's all
I know.

In article <ddspqq$5p3$1@digitaldaemon.com>, AJG says...
>Personally, all my debugging efforts have failed miserably. I can't even get GDB (various versions) to run my D programs _at all_ under linux. Sigh... this is an area that could really use improvement.

I'm starting to wonder if what we need at a higher level is an open source D-to-C program (written in D, of course). We could compile with dmc, gcc, etc.

The resulting C code could be beefed up with stack tracing/management code and other goodies as we need them. Or maybe debugged directly. We could fix syntax problems like "if(int x = foo()) { <use x>" and so on. With more imagination, we could probably double the list of benefits.

Another idea is to write a D-to-D translator. That would be even easier since the target language is identical (or in the case of language changes, near-identical). The generated D would look different from the original source to the extent that debugging aids were turned on and language features had been tweaked.

Something like:
> d2d -debug -stack -trace-mem MyProgram.d

which would do the translation and invoke dmd.exe to finish off compilation.
Hypothetically:
* "-stack" turns on whatever is needed to ask for stacks programmatically and to
dump them on uncaught errors.
* "-trace-mem" turns on whatever is needed to write stats on object creation and
destruction during execution.

Although I feel a little silly proprosing something I don't have time to work on. :-)  However, I've read references to a D front end. Is that in D? If so, d2d could be written in D which is certainly more productive than writing anything in C or C++.

d2d could be our escape hatch for when we need to enhance D sooner rather than later.

Reactions?

-Chuck

Chuck.Esterbrook /at/ gmail /dot/ com wrote:
> What debuggers, if any, are people actually using with their DMD programs on
> Windows? You know: setting breakpoints, examining a live stack when an error
> occurs, etc.
> 
> Does the one with DMC work with DMD executables?
> http://www.digitalmars.com/ugr/chapter23.html
> 
> 
> Thanks,
> -Chuck
> 
> 

I started lurking around trying to figure out how to do basic debugging on windows ..

You can actually use WinDbg to step through the source code and set break points.

First you're gonna have to download some debugging tools for windows:
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

you can use cdb from the command line or you windbg (gui wrapper around cdb).

Before you use cdb you need to add its path to the system path variable.

Now to show an example of stepping through the code:
setup a directory and create a .d file in it (I called it test.d) and just write some code, like:
<code>
import std.stdio;

void main()
{
	writefln("hello world!");
	writefln("line 2");
	writefln("this is the third line!");
	writefln("4th line");
}
</code>
compile it with -g and -debug
#dmd test.d -g -debug
that should create a test.exe for you
now load it with cdb
#cdb test
you'll see some crap which you can ignore for now.

what we want is to start at the program's main() function and step through lines one by one.

by default, cdb will be in "assembly mode", i.e. it will show you assembly commands and memore offsets, instead of source lines.

we can issue few commands to cdb to switch to "source mode".
#l+l
#l+s
#l+t
#l+o
#.lines

there is still another thing .. cdb doesn't know what is our source file, so we have to tell it to load it
#lsf test.d

next, set a break point at the program's start, which btw is _Dmain, not main
#bp _Dmain
and you can ignore error messeges.

now let the program run till it reaches that break point:
#g

now you can step through with
#p

and step inside functions with
#t

if you press Enter on the keyboard, the last command will be repeated.

That's all I could figure out by now.

You can do the same things with windbg.

open WinDbg, and go
File->Open Source file
and load test.d
then
File->Open Executable
and load test.exe

ignore the workspace dialoge (choose anything .. yes or no .. I don't know what that does).
Then
View->Command

Then make sure that
Debug -> Source Mode
is checked. (that takes care of all the l+ options)

now, in the command window set the break point to _Dmain like last time and run the program
#bp _Dmain
#g

now you can use the GUI buttons to step through the code.

One thing I noticed, if you declare a variable but never use it, the line numbers will be off by one.

Hasan Aljudy wrote:
> Chuck.Esterbrook /at/ gmail /dot/ com wrote:
> 
>> What debuggers, if any, are people actually using with their DMD programs on
>> Windows? You know: setting breakpoints, examining a live stack when an error
>> occurs, etc.
>>
>> Does the one with DMC work with DMD executables?
>> http://www.digitalmars.com/ugr/chapter23.html
>>
>>
>> Thanks,
>> -Chuck
>>
>>
> 
> I started lurking around trying to figure out how to do basic debugging on windows ..
> 
> You can actually use WinDbg to step through the source code and set break points.
> 
> First you're gonna have to download some debugging tools for windows:
> http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
> 
> you can use cdb from the command line or you windbg (gui wrapper around cdb).
> 
> Before you use cdb you need to add its path to the system path variable.
> 
> Now to show an example of stepping through the code:
> setup a directory and create a .d file in it (I called it test.d) and just write some code, like:
> <code>
> import std.stdio;
> 
> void main()
> {
>     writefln("hello world!");
>     writefln("line 2");
>     writefln("this is the third line!");
>     writefln("4th line");
> }
> </code>
> compile it with -g and -debug
> #dmd test.d -g -debug
> that should create a test.exe for you
> now load it with cdb
> #cdb test
> you'll see some crap which you can ignore for now.
> 
> what we want is to start at the program's main() function and step through lines one by one.
> 
> by default, cdb will be in "assembly mode", i.e. it will show you assembly commands and memore offsets, instead of source lines.
> 
> we can issue few commands to cdb to switch to "source mode".
> #l+l
> #l+s
> #l+t
> #l+o
> #.lines
> 
> there is still another thing .. cdb doesn't know what is our source file, so we have to tell it to load it
> #lsf test.d
> 
> next, set a break point at the program's start, which btw is _Dmain, not main
> #bp _Dmain
> and you can ignore error messeges.
> 
> now let the program run till it reaches that break point:
> #g
> 
> now you can step through with
> #p
> 
> and step inside functions with
> #t
> 
> if you press Enter on the keyboard, the last command will be repeated.
> 
> That's all I could figure out by now.
> 
> You can do the same things with windbg.
> 
> open WinDbg, and go
> File->Open Source file
> and load test.d
> then
> File->Open Executable
> and load test.exe
> 
> ignore the workspace dialoge (choose anything .. yes or no .. I don't know what that does).
> Then
> View->Command
> 
> Then make sure that
> Debug -> Source Mode
> is checked. (that takes care of all the l+ options)
> 
> now, in the command window set the break point to _Dmain like last time and run the program
> #bp _Dmain
> #g
> 
> now you can use the GUI buttons to step through the code.
> 
> One thing I noticed, if you declare a variable but never use it, the line numbers will be off by one.

aw, a little correction: you don't need the lsf command .. cdb will know which source files it needs.

Hi,

>It's not in D yet (that's what the OP was requesting and it's what Maxime was working on).

Hm... is that "yet" official?

>The links I posted in my first reply to this thread
>http://www.digitalmars.com/d/archives/digitalmars/D/22562.html
>http://www.digitalmars.com/d/archives/digitalmars/D/22967.html
>are the only clues I know about for getting it implemented. I haven't
>checked some of the other replys on this thread for more details. That's all
>I know.

Ok, thanks. So did Walter ever comment on this? I didn't see any replies in either thread (or this one).

Cheers,
--AJG.