November 22, 2006
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
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
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
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
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
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
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
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
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
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