ping?

On Wed, Jul 3, 2013 at 5:42 PM, Timothee Cour <thelastmammoth@gmail.com>wrote:

> I'd like to have a function:
> string mangle(string mangled_string);
> unittest{
>   void foo(int x){}
>   assert(foo.mangleof.demangle.mangle == foo.mangleof);
> }
>
> is there such a functionality, even partially?
>
>
>

As far as I know, no such function exists (outside of dmd itself).

On Wed, Jul 10, 2013 at 9:11 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> As far as I know, no such function exists (outside of dmd itself).
>

Do you have a pointer for that function in dmd ?
Again, I'm not talking about
symbol => mangled string
but about
demangled string=> mangled string

On Wednesday, 10 July 2013 at 16:30:25 UTC, Timothee Cour wrote:
> Do you have a pointer for that function in dmd ?

The compiler doesn't do it as one function, I mean it can parse as string and mangle it in the process of compiling code.

To go from demangled string => mangled string, you'd first parse the demangled string as a declaration and turn it into a symbol, then mangle that symbol.


But.... if you just want to do really simple cases, maybe this isn't too hard. I just quickly slapped this file together:

http://arsdnet.net/dcode/mangle.d


It is very basic, but might work for a lot of cases - it handled some basic functions I tried. Perhaps not too hard to add support for more from here.

As you can see by looking at the code, the way it works is:

1) tokenize the input string (it does this in a stupid way, and doesn't know all of D's symbols and keywords, but it doesn't have to be too smart since demangle produces fairly predictable input, so I think it will be ok).

2) runs a simple, stupid parser to get the components of the function - return type, name, and arguments. To add support for templates, extern(C), and so on, this would need to be expanded.

3) put the pieces back together in a wholly mangled form, borrowing one helper array from core.demangle.



There's a main function at the bottom of the file that does one of the few tests I tried with it.

Thanks much, that's a good start.
Template support would definitely be needed as it's so common.
This should go in std.demangle (or maybe a new std.mangle)

* One use case is using it in shared libraries:
user asks for a symbol via its demangled string representation (which is
most natural for user), then the string is mangled, and then calls dlsym to
retrieve the actual pointer to symbol in the shared lib.
* Another is in REPL where we can optimize certain calls by bypassing the
compiler, when the symbol already exists in main executable.
* There are other use cases

So this is worth doing.

On Wed, Jul 10, 2013 at 10:30 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Wednesday, 10 July 2013 at 16:30:25 UTC, Timothee Cour wrote:
>
>> Do you have a pointer for that function in dmd ?
>>
>
> The compiler doesn't do it as one function, I mean it can parse as string and mangle it in the process of compiling code.
>
> To go from demangled string => mangled string, you'd first parse the demangled string as a declaration and turn it into a symbol, then mangle that symbol.
>
>
> But.... if you just want to do really simple cases, maybe this isn't too hard. I just quickly slapped this file together:
>
> http://arsdnet.net/dcode/**mangle.d <http://arsdnet.net/dcode/mangle.d>
>
>
> It is very basic, but might work for a lot of cases - it handled some basic functions I tried. Perhaps not too hard to add support for more from here.
>
> As you can see by looking at the code, the way it works is:
>
> 1) tokenize the input string (it does this in a stupid way, and doesn't know all of D's symbols and keywords, but it doesn't have to be too smart since demangle produces fairly predictable input, so I think it will be ok).
>
> 2) runs a simple, stupid parser to get the components of the function - return type, name, and arguments. To add support for templates, extern(C), and so on, this would need to be expanded.
>
> 3) put the pieces back together in a wholly mangled form, borrowing one helper array from core.demangle.
>
>
>
> There's a main function at the bottom of the file that does one of the few tests I tried with it.
>

On Wed, Jul 10, 2013 at 10:30 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Wednesday, 10 July 2013 at 16:30:25 UTC, Timothee Cour wrote:
>
>> Do you have a pointer for that function in dmd ?
>>
>
> The compiler doesn't do it as one function, I mean it can parse as string and mangle it in the process of compiling code.
>
> To go from demangled string => mangled string, you'd first parse the demangled string as a declaration and turn it into a symbol, then mangle that symbol.
>
>
> But.... if you just want to do really simple cases, maybe this isn't too hard. I just quickly slapped this file together:
>
> http://arsdnet.net/dcode/**mangle.d <http://arsdnet.net/dcode/mangle.d>
>
>
> It is very basic, but might work for a lot of cases - it handled some basic functions I tried. Perhaps not too hard to add support for more from here.
>
> As you can see by looking at the code, the way it works is:
>
> 1) tokenize the input string (it does this in a stupid way, and doesn't know all of D's symbols and keywords, but it doesn't have to be too smart since demangle produces fairly predictable input, so I think it will be ok).
>
> 2) runs a simple, stupid parser to get the components of the function - return type, name, and arguments. To add support for templates, extern(C), and so on, this would need to be expanded.
>
> 3) put the pieces back together in a wholly mangled form, borrowing one helper array from core.demangle.
>
>
>
> There's a main function at the bottom of the file that does one of the few tests I tried with it.
>


also, can you push it to
your misc-stuff-including-D-programming-language-web-stuff git repo?

On Jul 10, 2013, at 10:44 AM, Timothee Cour <thelastmammoth@gmail.com> wrote:

> Thanks much, that's a good start.
> Template support would definitely be needed as it's so common.
> This should go in std.demangle (or maybe a new std.mangle)

core.mangle/demangle.  It would have to be done in a way that avoided allocating though (similar to core.demangle), to be in core.

On Wednesday, 10 July 2013 at 17:44:51 UTC, Timothee Cour wrote:
> * One use case is using it in shared libraries:
> user asks for a symbol via its demangled string representation (which is most natural for user), then the string is mangled, and then calls dlsym to retrieve the actual pointer to symbol in the shared lib.

I think in this case, it would be better to use .mangleof anyway because you'll want that type safety. You could still compare a user inputted string to typeof(S).stringof if you want to choose one at runtime.

I'll look at the github in a bit, in the middle of a bunch of stuff now.

On Wed, Jul 10, 2013 at 11:39 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> On Wednesday, 10 July 2013 at 17:44:51 UTC, Timothee Cour wrote:
>
>> * One use case is using it in shared libraries:
>> user asks for a symbol via its demangled string representation (which is
>> most natural for user), then the string is mangled, and then calls dlsym to
>> retrieve the actual pointer to symbol in the shared lib.
>>
>
> I think in this case, it would be better to use .mangleof anyway because you'll want that type safety. You could still compare a user inputted string to typeof(S).stringof if you want to choose one at runtime.
>

How would that work, since this is runtime only? I'm interested in the case where I don't have access to said symbol, all I have is a string representation of it. For example when using dlopen on a library where we don't have source code; so in this case typeof(S) doesn't make sense.

On Wednesday, 10 July 2013 at 19:03:22 UTC, Timothee Cour wrote:
> How would that work, since this is runtime only?

Take a pointer with the right type and then attach the rest of the name to it. Given:

int foo(int a, string) { return a;}

void main() {
        int function(int, string) fooPtr;
        pragma(msg, foo.mangleof);
        pragma(msg, typeof(fooPtr).mangleof);
}

You get:

_D6test303fooFiAyaZi
PFiAyaZi


The first part of the full name is pretty simple: _Dnamehere, where namehere is length pf the part, then the part.

length 6, string "test30
length 3, string "foo"

total name: test30.foo



Then after that, comes the type: a 'F'unction that returns 'int' with arguments (in reverse order) 'A'rray of immutable ('y') char ('a'), then the 'Z' final argument 'i'nt.


The second line shows a 'P'ointer to that same typed symbol.


If you want to get the foo function out of a library, you'd probably go:


fooptr = cast(typeof(fooptr)) dlsym(handle, "_D6test303fooFiAyaZi");


Then you can use fooptr. Without knowing the static type of the function though, it isn't safe to use - you could pass it wrong arguments and ruin your day. So having the statically typed function pointer is very useful.


Since we have that, we can get a name from the user and put it together:


fooptr = cast(typeof(fooptr)) dlsym(handle, "_D" ~ mangleName("test30.foo") ~ typeof(fooptr).mangleof[1 .. $]);

Cut the 'P' off the fooptr mangle and attach that to the name's mangle, and we have the full name.



If you want to ask for the type from the user too, what I'd do is compare it against the various options you know how to handle:


foreach(type; TypeTuple!(int function(int, string), int function() /* and whatever else you want */)  {
    if(userEnteredString == type.stringof) {
        type ptr = cast(type) dlsym(handle, "_D" ~ mangleName(userEnteredName) ~ type.mangleof[1 .. $]);
        if(ptr is null) throw new Exception("not found in library");
    }
}

/* otherwise, throw that the user entered type isn't supported */




So, of course, this limits you to the list of supported function signatures, but I think you realistically are anyway since getting the ABI right at runtime from arbitrary input isn't going to be easy.