there is also a problem with Tango in Ddbg prior to 0.0.4.4, which i've just put on the website.

To enable Ddbg to catch unhandled exceptions in Tango applications, you
need to rebuild Tango's phobos.lib after changing
in tango\lib\compiler\dmd\dmain2.d, currently line 83
bool trapException = true;
to
extern(C) bool trapException = true;

Here is why:
With the default exception handler in dmain2.d enabled, Win32 will not
report unhandled exceptions to the debugger.
To not require the author of the debuggee to manually change this, just
to be able to use the debugger for stack traces, Ddbg changes the value
of no_catch_exceptions in standard Phobos to true and trapException to
false before running the debuggee.
However, the latter is only possible, if the address of that variable is
exported.


Sean Kelly wrote:
> Jascha Wetzel wrote:
>> Ddbg is a Win32 D Debugger
>>
>> http://ddbg.mainia.de/releases.html
>>
>> This release mainly adds support for type cast and associative arrays. Type casts can be used to workaround the missing array and enum support in DMD's debug symbols.
> 
> A few things so far.  The final example may actually be a problem with rebuild, but I thought I'd include it anyway.
> 
> ======================================================================
> 
> C:\code\src\d\test>ddbg test.exe
> Ddbg v0.0.4.3 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> 
> ->dr
> 
> 
> ----------------------------------------
> Unhandled exception in Ddbg v0.0.4.3 alpha:
> Access Violation
> 
> Please report this problem!
> See the http://ddbg.mainia.de/releases.html for details.
> Thank you!
> 
> C:\code\src\d\test>
> C:\code\src\d\test>
> C:\code\src\d\test>
> C:\code\src\d\test>ddbg test.exe
> Ddbg v0.0.4.3 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> 
> ->ds
> 
> 
> ----------------------------------------
> Unhandled exception in Ddbg v0.0.4.3 alpha:
> Access Violation
> 
> Please report this problem!
> See the http://ddbg.mainia.de/releases.html for details.
> Thank you!
> 
> ======================================================================
> 
> 
> C:\code\src\d\test>cat test.d
> import tango.util.collection.LinkSeq;
> import tango.stdc.stdio;
> 
> LinkSeq!(C) cont;
> 
> static this()
> {
>     cont = new LinkSeq!(C);
> }
> 
> class C
> {
>     int x;
> }
> 
> void main()
> {
>     printf( "hello\n" );
> }
> 
> C:\code\src\d\test>rebuild -g test
> c:\bin\dmd\bin\..\..\dm\bin\link.exe
> .\test+.\tango-util-collection-LinkSeq+.\ta
> ngo-util-collection-model-Iterator+.\tango-util-collection-model-Sortable+.\tang
> 
> o-util-collection-model-Dispenser+.\tango-util-collection-model-View+.\tango-uti
> 
> l-collection-model-GuardIterator+.\tango-util-collection-model-Comparator+.\tang
> 
> o-util-collection-impl-LLCell+.\tango-util-collection-impl-Cell+.\tango-util-col
> 
> lection-impl-SeqCollection+.\tango-util-collection-model-Seq+.\tango-util-collec
> 
> tion-model-SeqView+.\tango-util-collection-impl-Collection+.\tango-io-protocol-m
> 
> odel-IReader+.\tango-io-model-IBuffer+.\tango-io-model-IConduit+.\tango-io-proto
> 
> col-model-IProtocol+.\tango-io-protocol-model-IWriter+.\tango-util-collection-im
> 
> pl-AbstractIterator+.\tango-stdc-stdio+.\tango-stdc-stdarg+.\tango-stdc-stddef+.
> 
> \tango-stdc-config,test.exe,,user32+kernel32/noi;
> 
> C:\code\src\d\test>ddbg test.exe
> Ddbg v0.0.4.3 alpha - D Debugger
> Copyright (c) 2007 Jascha Wetzel
> http://ddbg.mainia.de/
> 
> 
> 
> ----------------------------------------
> Unhandled exception in Ddbg v0.0.4.3 alpha:
> No symbolic debug info present (no debugging symbols found), try
> compiling and l
> inking with -g
> 
> Please report this problem!
> See the http://ddbg.mainia.de/releases.html for details.
> Thank you!
> 
> C:\code\src\d\test>

Jascha Wetzel wrote:
> there is also a problem with Tango in Ddbg prior to 0.0.4.4, which i've
> just put on the website.
> 
> To enable Ddbg to catch unhandled exceptions in Tango applications, you
> need to rebuild Tango's phobos.lib after changing
> in tango\lib\compiler\dmd\dmain2.d, currently line 83
> bool trapException = true;
> to
> extern(C) bool trapException = true;
> 
> Here is why:
> With the default exception handler in dmain2.d enabled, Win32 will not
> report unhandled exceptions to the debugger.
> To not require the author of the debuggee to manually change this, just
> to be able to use the debugger for stack traces, Ddbg changes the value
> of no_catch_exceptions in standard Phobos to true and trapException to
> false before running the debuggee.
> However, the latter is only possible, if the address of that variable is
> exported.

Okay, that makes sense.  I don't suppose it could execute cr_trapExeptions(false) instead? :-)

i thought about that first, so i wouldn't have to patch tango.
the problem is, that the linker strips cr_trapExeptions from the exe
unless it's called somewhere.
one could call it in main to initialize the variable, instead of
initializing it statically. but that would require a change as well.
maybe it's preferable to not have another export, though.

it would be nice if you could submit one of the changes to the SVN.

Sean Kelly wrote:
> Jascha Wetzel wrote:
>> there is also a problem with Tango in Ddbg prior to 0.0.4.4, which i've just put on the website.
>>
>> To enable Ddbg to catch unhandled exceptions in Tango applications, you
>> need to rebuild Tango's phobos.lib after changing
>> in tango\lib\compiler\dmd\dmain2.d, currently line 83
>> bool trapException = true;
>> to
>> extern(C) bool trapException = true;
>>
>> Here is why:
>> With the default exception handler in dmain2.d enabled, Win32 will not
>> report unhandled exceptions to the debugger.
>> To not require the author of the debuggee to manually change this, just
>> to be able to use the debugger for stack traces, Ddbg changes the value
>> of no_catch_exceptions in standard Phobos to true and trapException to
>> false before running the debuggee.
>> However, the latter is only possible, if the address of that variable is
>> exported.
> 
> Okay, that makes sense.  I don't suppose it could execute
> cr_trapExeptions(false) instead? :-)

Jascha Wetzel wrote:
> i thought about that first, so i wouldn't have to patch tango.
> the problem is, that the linker strips cr_trapExeptions from the exe
> unless it's called somewhere.
> one could call it in main to initialize the variable, instead of
> initializing it statically. but that would require a change as well.
> maybe it's preferable to not have another export, though.

No problem.  I thought about this a bit more this morning and I think I'm just going expose the variable as you suggest.  It will either be named "trapExceptions" or "cr_trapExceptions" -- I haven't decided yet (but probably the former).



Sean

Jascha Wetzel wrote:
> oh wait, you're one of the ddl.coff authors, right?
> if you happen to be interested in the codeview stuff from ddbg or
> something, i'll donate this to the ddl project anytime...
> 
> J Duncan wrote:
>> Jascha Wetzel wrote:
>>> the source isn't in best shape. but i've put it here for you:
>>> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
>>> the license is proprietary, so it's just food for curiosity.
>>>
>> Very cool, thank you very much.

Awesome! That would be cool, I am porting some stuff to Tango right now and am planning to convert at least ddl.coff to tango soon. I will definitely look into including your stuff as it looks like its more refined than the stuff piled into ddl.coff....

great! since i'm maintaining that code anyway, it would be convenient if we could agree on small changes that make the code usable to both projects. then i could submit updates easily.

J Duncan wrote:
> Jascha Wetzel wrote:
>> oh wait, you're one of the ddl.coff authors, right?
>> if you happen to be interested in the codeview stuff from ddbg or
>> something, i'll donate this to the ddl project anytime...
>>
>> J Duncan wrote:
>>> Jascha Wetzel wrote:
>>>> the source isn't in best shape. but i've put it here for you:
>>>> http://ddbg.mainia.de/Ddbg-0.0.4.1-alpha-src.zip
>>>> the license is proprietary, so it's just food for curiosity.
>>>>
>>> Very cool, thank you very much.
> 
> Awesome! That would be cool, I am porting some stuff to Tango right now and am planning to convert at least ddl.coff to tango soon. I will definitely look into including your stuff as it looks like its more refined than the stuff piled into ddl.coff....

dmain2.d has another problem:
even with cr_trapExceptions=false, exceptions get handled. they just get
thrown again after being caught. therefore the stacktrace to the actual
location of the problem gets lost. with tango's dmain2.d the debugger
can only show the stacktrace to that throw statement, which is useless.
to fix this, the code needs to be more like the original dmain2, not
using a try/catch block at all, if cr_trapException=false.

Sean Kelly wrote:
> Jascha Wetzel wrote:
>> i thought about that first, so i wouldn't have to patch tango.
>> the problem is, that the linker strips cr_trapExeptions from the exe
>> unless it's called somewhere.
>> one could call it in main to initialize the variable, instead of
>> initializing it statically. but that would require a change as well.
>> maybe it's preferable to not have another export, though.
> 
> No problem.  I thought about this a bit more this morning and I think I'm just going expose the variable as you suggest.  It will either be named "trapExceptions" or "cr_trapExceptions" -- I haven't decided yet (but probably the former).
> 
> 
> 
> Sean

Jascha Wetzel wrote:
> dmain2.d has another problem:
> even with cr_trapExceptions=false, exceptions get handled. they just get
> thrown again after being caught. therefore the stacktrace to the actual
> location of the problem gets lost.

Darnit.  I was afraid of this, but when I tried it with VC++8 it seemed to work.

> with tango's dmain2.d the debugger
> can only show the stacktrace to that throw statement, which is useless.
> to fix this, the code needs to be more like the original dmain2, not
> using a try/catch block at all, if cr_trapException=false.

So the debugger would set cr_trapExceptions=false before C main is even executed?  Okay, I can change that.


Sean

Sean Kelly wrote:
> 
> So the debugger would set cr_trapExceptions=false before C main is even executed?  Okay, I can change that.

Done.  Changing cr_trapExceptions now only has an effect if done before C main is called, just like the flag in Phobos.


Sean

Jascha Wetzel wrote:
>i can't possibly
> think of anything else ddbg could ever need the curly brackets for. to
> be sure we could also use something else:
> §cast§
> #cast#
> :)

What if ddbg sometime in the future allows you to set the value of a struct by using a struct literal?

set point = { 5, 77 }

Might be a while until that feature materializes, but who knows. Setting variables during debugging comes in handy sometimes.