View mode: basic / threaded / horizontal-split · Log in · Help
November 23, 2006
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
Thomas Kuehne wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=588

Thanks!
November 24, 2006
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
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
Re: A new debugger for Linux - would it work for D?
Do you have any D code samples that confuse GDB? (bad line numbers, weird stack
unwinding, etc).

- Cristian
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home