View mode: basic / threaded / horizontal-split · Log in · Help
November 22, 2006
Re: A new debugger for Linux - would it work for D?
John Reimer wrote:
> On Wed, 22 Nov 2006 11:05:00 -0800, Craig Black <cblack@ara.com> wrote:
> 
>> Currently there is no debugger tailored for D, so this would be great and
>> appreciated by many.  However, how difficult would it be to make this
>> portable to Windows as well?  Most D developers use Windows primarily.
>>
>> -Craig
>>
>>
> 
> 
> Do they?  I wouldn't say that anymore.
> 
> -JJR

could be interesting to somehow get those numbers
November 22, 2006
Re: A new debugger for Linux - would it work for D?
On Wed, 22 Nov 2006 14:52:20 -0800, freeagle <dalibor.free@gmail.com>  
wrote:

> John Reimer wrote:
>> On Wed, 22 Nov 2006 11:05:00 -0800, Craig Black <cblack@ara.com> wrote:
>>
>>> Currently there is no debugger tailored for D, so this would be great  
>>> and
>>> appreciated by many.  However, how difficult would it be to make this
>>> portable to Windows as well?  Most D developers use Windows primarily.
>>>
>>> -Craig
>>>
>>>
>>   Do they?  I wouldn't say that anymore.
>>  -JJR
>
> could be interesting to somehow get those numbers


I agree.
November 23, 2006
Re: A new debugger for Linux - would it work for D?
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.
- The bug with local alias template parameters (depends on where it's 
instantiated from).
- Bugzilla bug #221, a one-character fix.
mtype.c line 174-175,

    mangleChar[Tbit] = 'b';
    mangleChar[Tbool] = 'x';

This should be changed so they are both 'b'.
- 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

for

void main()
{
  int abc;
}


making it distinguishable from
extern(Windows)
{
  int main3abci;
}

- template floating point value parameters should use big-endian order 
(with exponent first) which would be moderately human-readable, instead 
of the current order, which makes no sense.

expression.c line 1316 is currently

    for (int i = 0; i < REALSIZE-REALPAD; i++)
	buf->printf("%02x", p[i]);

but should be

    for (int i = REALSIZE-REALPAD-1; i >=0; i--)
	buf->printf("%02x", p[i]);

(Actually it would be even better if the implicit bit were stripped out 
for x86; that would make it more compatible across platforms, and would 
mean 0x1.123456789ABCDEDEp+0 would be mangled as:
"3FFF123456789ABCDEDE"
-- but proper cross-platform support needs a bit more thought).
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Don Clugston wrote:
> 
> - 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
> 
> for
> 
> void main()
> {
>   int abc;
> }
> 
> 
> making it distinguishable from
> extern(Windows)
> {
>   int main3abci;
> }
> 

Can we define functions that do not have D linkage, but have D name 
mangling? If so, does that even make sense? It was my understanding that 
any function with linkage other than D is used for obj/lib/dll level 
compatibility with other programs written in other languages (i.e., ABI 
level compatibility). As such, these other languages don't understand D 
name mangling but only C name mangling, so what's a non-D-linkage with 
D-name-mangling for?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Bruno Medeiros wrote:
> Don Clugston wrote:
>>
>> - 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
>>
>> for
>>
>> void main()
>> {
>>   int abc;
>> }
>>
>>
>> making it distinguishable from
>> extern(Windows)
>> {
>>   int main3abci;
>> }
>>
> 
> Can we define functions that do not have D linkage, but have D name 
> mangling? If so, does that even make sense? It was my understanding that 
> any function with linkage other than D is used for obj/lib/dll level 
> compatibility with other programs written in other languages (i.e., ABI 
> level compatibility). As such, these other languages don't understand D 
> name mangling but only C name mangling, so what's a non-D-linkage with 
> D-name-mangling for?

These symbols cannot be externally linked directly, but it can be 
important for eg alias template parameters. (Everything needs to be 
manglable, even it can't be linked directly).

extern(C) {

void func() {
  // 'func' uses C name mangling

  void inner() {
    // 'inner' uses D name mangling.
    // So 'func.inner' is a hybrid.
  }

}
}

It's even possible to have extern(Windows) inner functions inside 
extern(C) functions!
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Bruno Medeiros wrote:
> Can we define functions that do not have D linkage, but have D name 
> mangling?

Not as far as I know.

> If so, does that even make sense? It was my understanding that
> any function with linkage other than D is used for obj/lib/dll level 
> compatibility with other programs written in other languages (i.e., ABI 
> level compatibility). As such, these other languages don't understand D 
> name mangling but only C name mangling, so what's a non-D-linkage with 
> D-name-mangling for?

I have on several occasions declared functions as extern(C) in order to 
be able to access them from inline assembly. I needed to be sure about 
the calling convention, and at that time the D calling convention wasn't 
documented as well as it is now. (http://www.digitalmars.com/d/abi.html)
Name mangling is wholly irrelevant to this, though. In fact my 
backtraces would've looked better if all names had D mangling, so I 
would have liked name mangling to have been preserved.
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Frits van Bommel schrieb am 2006-11-23:
> Bruno Medeiros wrote:
>> Can we define functions that do not have D linkage, but have D name 
>> mangling?
>
> Not as far as I know.
>
> > If so, does that even make sense? It was my understanding that
>> any function with linkage other than D is used for obj/lib/dll level 
>> compatibility with other programs written in other languages (i.e., ABI 
>> level compatibility). As such, these other languages don't understand D 
>> name mangling but only C name mangling, so what's a non-D-linkage with 
>> D-name-mangling for?

# extern(C) void outer(){
#	void inner(){
#	}
# }

current mangling:
> outer
> outer5innerFZv

Don's proposal:
> outer
> 0U5outer5innerFZv

Thomas
November 23, 2006
Re: A new debugger for Linux - would it work for D?
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.

Thomas
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Walter Bright schrieb am 2006-11-22:
> 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?

http://d.puremagic.com/issues/show_bug.cgi?id=588
(though this doesn't handle any special cases)

Thomas
November 23, 2006
Re: A new debugger for Linux - would it work for D?
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Frits van Bommel schrieb am 2006-11-23:
>> Bruno Medeiros wrote:
>>> Can we define functions that do not have D linkage, but have D name 
>>> mangling?
>> Not as far as I know.
>>
>>> If so, does that even make sense? It was my understanding that
>>> any function with linkage other than D is used for obj/lib/dll level 
>>> compatibility with other programs written in other languages (i.e., ABI 
>>> level compatibility). As such, these other languages don't understand D 
>>> name mangling but only C name mangling, so what's a non-D-linkage with 
>>> D-name-mangling for?
> 
> # extern(C) void outer(){
> #	void inner(){
> #	}
> # }
> 
> current mangling:
>> outer
>> outer5innerFZv
> 
> Don's proposal:
>> outer
>> 0U5outer5innerFZv
> 
> Thomas
> 
> 

Ah, got it. But in terms of calling convention, is outer.inner still of 
regular D calling convention? (I think so, given some obj2asm tests I did)

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?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4
Top | Discussion index | About this forum | D home