November 23, 2006
Bruno Medeiros wrote:
> As for fixes, how about just mangling the inner function with a full D name mangling, treating the parent names as if they were D-mangled too?:
> _D4modl4funcFZv5innerFZv
> This way we (maybe) can't tell the calling convention of the parent functions... but does that matter?

It might matter for something like DDL if it wants to call a function in a dynamically-loaded module. It's kind of important to know the calling convention for that :). (Not sure if DDL currently does anything like this, but if not it might in the future)
November 23, 2006
Thomas Kuehne wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=588

Thanks!
November 24, 2006
I owe a clarification (especially since some of you have posted code in response to my demangling question).

Zero is NOT open source, and my long term intent is a commercially supported product (see some of my ramblings here: http://the-free-meme.blogspot.com/).

Also I see a lot of domain knowledge wrt the inner workings of D in this forum.

I thinks it would be a good idea (architecturally and ethically) that Zero provide hooks for D-supporting plugins and shared objects. Such modules could be open source themselves, or othewise licensed, as their respective authors see fit. The demangler for example is already based on a factory pattern (it deals with legacy gcc and the Itanium ABI), and delegating to a .so that implements D demangling would not be very hard to do.



November 24, 2006
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Don Clugston schrieb am 2006-11-23:
>> Walter Bright wrote:
>>> Don Clugston wrote:
>>>> Thomas K�hne wrote:
>>>>> Cristian Vlasceanu wrote:
>>>>>> D has a demangling scheme that is not compatible with C++?
>>>>>> Then that's another area that needs work in the debugger.
>>>>> see attachment
>>>>>
>>>>> Thomas
>>>> Wow, it's interesting to compare yours with my compile-time demangler. They are both about the same number of lines of code (and both seem more comprehensive than the one in Phobos).
>>> Would you two care to take the best of both, and we can replace the Phobos one?
>> I think there a couple of issues in the mangling algorithm which need to be addressed first.
> 
> <snip>
> 
>> - Items that use D mangling but don't have D linkage. I suggest changing those cases to use "0" then the linkage type ('W' for Windows, 'U', for C, etc, same as for delegate/function pointers), then the length.
>> So instead of
>> main3abci
>>
>> it would be
>> 0U4main3abci
> 
> I dislike unnecessary special cases:
> #
> # module wood;
> # # class Tree{
> #    static this(){
> #    }
> # #    ~this(){
> #    }
> # }
> # # extern(C) void outer(){
> #    extern(Windows) int middle(){
> #       void inner(){
> #       }
> #       return 0;
> #    }
> # }
> # 
> 
> DMD-0.174 generates the following symbols
> (special cases are marked by an asterisk):
>> _Class_4wood4Tree *
>> _D4wood4Tree11_staticCtorFZv
>> _D4wood4Tree5_dtorFZv
>> _init_4wood4Tree *
>> _modctor_4wood *
>> outer
>> outer6middleWZi *
>> outer6middleWZi5innerFZv *
>> _vtbl_4wood4Tree *
> 
> I propose the following mangling:
>> _D4wood4Tree9__Class__Pv
>> _D4wood4Tree12__staticCtorFZv
>> _D4wood4Tree6__dtorFZv
>> _D4wood4Tree8__init__Pv
>> _D4wood11__modctor__FZv
>> outer
>> _D4wood5outerFZv6middleWZi
>> _D4wood5outerFZv6middleWZi5innerFZv
>> _D4wood4Tree8__vtbl__Av
> 
> There are no special cases(identifiers starting with two underscores are
> reserved), thus no need for the demangler to know anything about the RT's
> internals.

Agreed, I like that *much* better than my proposal.
BTW, unittest is another special case, and should be treated in the same way.
- Don.
November 24, 2006
Cristian Vlasceanu wrote:
> I owe a clarification (especially since some of you have posted code in response
> to my demangling question).
> 
> Zero is NOT open source, and my long term intent is a commercially supported
> product (see some of my ramblings here: http://the-free-meme.blogspot.com/).

Well, Thomas's code is GPL-with-exception, so you can link it to a commercial program without any problem, as long as you distribute any modifications to his source.

> Also I see a lot of domain knowledge wrt the inner workings of D in this forum.
> 
> I thinks it would be a good idea (architecturally and ethically) that Zero provide
> hooks for D-supporting plugins and shared objects. Such modules could be open
> source themselves, or othewise licensed, as their respective authors see fit. The
> demangler for example is already based on a factory pattern (it deals with legacy
> gcc and the Itanium ABI), and delegating to a .so that implements D demangling
> would not be very hard to do.

That would work as well, of course.
November 24, 2006
Frits van Bommel wrote:
>> I thinks it would be a good idea (architecturally and ethically) that Zero provide
>> hooks for D-supporting plugins and shared objects. Such modules could be open
>> source themselves, or othewise licensed, as their respective authors see fit. The
>> demangler for example is already based on a factory pattern (it deals with legacy
>> gcc and the Itanium ABI), and delegating to a .so that implements D demangling
>> would not be very hard to do.
> 
> That would work as well, of course.

It would be better for D users if support was built in, so it would work out of the box with no hassle. Having the hooks for plugins, however, is still a very good idea and should be done. That will help future proof the debugger.
November 24, 2006
Walter Bright wrote:
> Frits van Bommel wrote:
>>> I thinks it would be a good idea (architecturally and ethically) that Zero provide
>>> hooks for D-supporting plugins and shared objects. Such modules could be open
>>> source themselves, or othewise licensed, as their respective authors see fit. The
>>> demangler for example is already based on a factory pattern (it deals with legacy
>>> gcc and the Itanium ABI), and delegating to a .so that implements D demangling
>>> would not be very hard to do.
>>
>> That would work as well, of course.
> 
> It would be better for D users if support was built in, so it would work out of the box with no hassle. Having the hooks for plugins, however, is still a very good idea and should be done. That will help future proof the debugger.

You could ship it with the plug in pre-installed.
November 25, 2006
BCS wrote:
> Walter Bright wrote:
>> Frits van Bommel wrote:
>>>> I thinks it would be a good idea (architecturally and ethically) that Zero provide
>>>> hooks for D-supporting plugins and shared objects. Such modules could be open
>>>> source themselves, or othewise licensed, as their respective authors see fit. The
>>>> demangler for example is already based on a factory pattern (it deals with legacy
>>>> gcc and the Itanium ABI), and delegating to a .so that implements D demangling
>>>> would not be very hard to do.
>>>
>>> That would work as well, of course.
>>
>> It would be better for D users if support was built in, so it would work out of the box with no hassle. Having the hooks for plugins, however, is still a very good idea and should be done. That will help future proof the debugger.
> 
> You could ship it with the plug in pre-installed.

Yes this is exactly what I have in mind, by  "hooks and plugins" I meant  to have the D support *dynamically* linked in, so that it can be upgraded or replaced without having to recompile the debugger.

November 30, 2006
Do you have any D code samples that confuse GDB? (bad line numbers, weird stack
unwinding, etc).

 - Cristian

1 2 3 4
Next ›   Last »