Thread overview
Who has a std.demangle that works with 0.177?
Dec 21, 2006
Lionello Lunesu
Dec 21, 2006
Lutger
Dec 21, 2006
Lionello Lunesu
Dec 21, 2006
Ary Manzana
Dec 21, 2006
Thomas Kuehne
Dec 21, 2006
Lionello Lunesu
Dec 21, 2006
Lionello Lunesu
Dec 21, 2006
Brad Roberts
December 21, 2006
I'm writing a little program that generates a .di file from obj/lib.

Needless to say, it makes heavy use of std.demangle, but that module was not updated for the changed name mangling in 0.177. My program works 'fine' for 0.176, but not for 0.177 (see results at end of mail).

I saw some bugzilla entries related to the name mangling, but they are all pre-0.176, so not related to my problem.

Can anybody tell me what needs to change in std.demangle? A patch perhaps?

Thanks,

L.

module somesym;
interface some_interface {    // (*)
    void dump();
}
class some_class : some_interface {
    void member() { printf("pseop"); }

    this() { printf("this"); }
    ~this() { printf("~this"); }

    final void final_func() {}

    struct nested{
	int a=void;
	void nestedmember(){ printf("%i",a);}
    }	
    nested structmember;
    void dump() { printf("dump"); }
}


0.176:

somesym: void some_class.member();
somesym: class some_class somesym.some_class._ctor();
somesym: void some_class._dtor();
somesym: void some_class.final_func();
somesym: Z some_interface.__Interface;
somesym: void some_class.nested.nestedmember();
somesym: void some_class.dump();
somesym: Z some_class.nested.__init;
somesym: Z some_class.__init;
somesym: Z some_class.__Class;
somesym: Z some_class.__vtbl;

0.177:

somesym: MFZv some_class.member;
somesym: MFZC7somesym10some_class some_class._ctor;
somesym: MFZv some_class._dtor;
somesym: MFZv some_class.final_func;
TypeInfo_S7somesym10some_class6nested: Z __init;
somesym: Z some_interface.__Interface;
somesym: MFZv some_class.nested.nestedmember;
somesym: MFZv some_class.dump;
somesym: Z some_class.nested.__init;
somesym: Z some_class.__init;
somesym: Z some_class.__Class;
somesym: Z some_class.__vtbl;


* Of course, interfaces will not be supported since their members don't generate any symbols. (Would be cool if they did though, perhaps a {assert(0);} default implementation?)
December 21, 2006
Lionello Lunesu wrote:
> I'm writing a little program that generates a .di file from obj/lib.
> 
> Needless to say, it makes heavy use of std.demangle, but that module was not updated for the changed name mangling in 0.177. My program works 'fine' for 0.176, but not for 0.177 (see results at end of mail).
> 
> I saw some bugzilla entries related to the name mangling, but they are all pre-0.176, so not related to my problem.
> 
> Can anybody tell me what needs to change in std.demangle? A patch perhaps?
> 
> Thanks,
> 
> L.

Try this:

insert the following at around line 200:
    case 'M':
    p = parseType();
    goto L1;

This will take care of types that need a this pointer.

Then for nested types do as in that patch, change the following in std.demangle (line 463-465) from:

    if (ni != name.length)
        goto Lnot;
    return result;

to:

    while(ni < name.length)
    {
        result ~= " . " ~ parseType(parseQualifiedName());
    }

    if (ni != name.length)
        goto Lnot;
    return result;

I believe that's it, correct me if I'm wrong.


December 21, 2006
Lionello Lunesu escribió:
> I'm writing a little program that generates a .di file from obj/lib.

I was wondering if this could be used in an IDE for autocompletion, even if the source file is missing. Like JDT autocompletes with .class information without having the .java source file. Is it possible using your program for that?
December 21, 2006
Ary Manzana schrieb am 2006-12-21:
> Lionello Lunesu escribió:
>> I'm writing a little program that generates a .di file from obj/lib.
>
> I was wondering if this could be used in an IDE for autocompletion, even if the source file is missing. Like JDT autocompletes with .class information without having the .java source file. Is it possible using your program for that?

That is impossible, unless his tool analyses the object code associated with the symbols. Attributes like "final" aren't mangled and non-function members of structs and classes don't have symbols in the object code.

Thomas


December 21, 2006
"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:emeglc$20br$1@digitaldaemon.com...
> Lionello Lunesu escribió:
>> I'm writing a little program that generates a .di file from obj/lib.
>
> I was wondering if this could be used in an IDE for autocompletion, even if the source file is missing. Like JDT autocompletes with .class information without having the .java source file. Is it possible using your program for that?

I think so. I'm hoping to get something that could eventually be built into DMD so that it's no longer needed to provide a D-interface file (.di) for libs. Of course, it all depends on the name mangling, but at the moment D's mangling quite a lot of information. I'm not sure yet what's missing (Thomas mentioned 'final', and I know interfaces aren't visible in the library) but it'll be useful is many cases nonetheless.

L.


December 21, 2006
"Thomas Kuehne" <thomas-dloop@kuehne.cn> wrote in message news:slrneom2jc.8l8.thomas-dloop@birke.kuehne.cn...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ary Manzana schrieb am 2006-12-21:
>> Lionello Lunesu escribió:
>>> I'm writing a little program that generates a .di file from obj/lib.
>>
>> I was wondering if this could be used in an IDE for autocompletion, even if the source file is missing. Like JDT autocompletes with .class information without having the .java source file. Is it possible using your program for that?
>
> That is impossible, unless his tool analyses the object code associated with the symbols. Attributes like "final" aren't mangled and non-function members of structs and classes don't have symbols in the object code.

Some restrictions I can live with :) The question is, how much is needed to be able to link to a lib and being able to call functions, instantiate objects in it..

"Final" IS a problem, indeed. Final methods will not end up in the vtbl, and calling a final function that's not tagged as such will either call the wrong function or generate an AV.. D's already mangling a lot of info, why not "final"?

Eventually, I would love to be able to use libs and objs without their source/header. If this is already almost possible, we might as well support it all the way.

L.


December 21, 2006
Thanks! I'll give it a try..

L.

"Lutger" <lutger.blijdestijn@gmail.com> wrote in message news:eme81p$1m6n$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>> I'm writing a little program that generates a .di file from obj/lib.
>>
>> Needless to say, it makes heavy use of std.demangle, but that module was not updated for the changed name mangling in 0.177. My program works 'fine' for 0.176, but not for 0.177 (see results at end of mail).
>>
>> I saw some bugzilla entries related to the name mangling, but they are all pre-0.176, so not related to my problem.
>>
>> Can anybody tell me what needs to change in std.demangle? A patch perhaps?
>>
>> Thanks,
>>
>> L.
>
> Try this:
>
> insert the following at around line 200:
>     case 'M':
>     p = parseType();
>     goto L1;
>
> This will take care of types that need a this pointer.
>
> Then for nested types do as in that patch, change the following in std.demangle (line 463-465) from:
>
>     if (ni != name.length)
>         goto Lnot;
>     return result;
>
> to:
>
>     while(ni < name.length)
>     {
>         result ~= " . " ~ parseType(parseQualifiedName());
>     }
>
>     if (ni != name.length)
>         goto Lnot;
>     return result;
>
> I believe that's it, correct me if I'm wrong.
>
> 


December 21, 2006
On Thu, 21 Dec 2006, Lionello Lunesu wrote:

> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:emeglc$20br$1@digitaldaemon.com...
> > Lionello Lunesu escribió:
> >> I'm writing a little program that generates a .di file from obj/lib.
> >
> > I was wondering if this could be used in an IDE for autocompletion, even if the source file is missing. Like JDT autocompletes with .class information without having the .java source file. Is it possible using your program for that?
> 
> I think so. I'm hoping to get something that could eventually be built into DMD so that it's no longer needed to provide a D-interface file (.di) for libs. Of course, it all depends on the name mangling, but at the moment D's mangling quite a lot of information. I'm not sure yet what's missing (Thomas mentioned 'final', and I know interfaces aren't visible in the library) but it'll be useful is many cases nonetheless.
> 
> L.

There's a lot of info that you'd loose the ability to get.  Anything that doesn't result in a symbol, for instance.  Some examples:  Enums, aliases, typedefs, imports.