View mode: basic / threaded / horizontal-split · Log in · Help
December 21, 2006
Who has a std.demangle that works with 0.177?
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
Re: Who has a std.demangle that works with 0.177?
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
Re: Who has a std.demangle that works with 0.177?
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
Re: Who has a std.demangle that works with 0.177?
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
Re: Who has a std.demangle that works with 0.177?
"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
Re: Who has a std.demangle that works with 0.177?
"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
Re: Who has a std.demangle that works with 0.177?
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
Re: Who has a std.demangle that works with 0.177?
Don't know how parse multipart/mixed message
Top | Discussion index | About this forum | D home