C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Implementing a mangling tool          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Ganesh Guest Posted: Mon Aug 09, 2004 8:54 pm    Post subject: Implementing a mangling tool Demanglers are widely used tools and very useful ones too, but are there any mangling tools? Such a tool would be very useful in various cases; for example, foo = dl_sym("_implementation_specific_mangled_name"); In this case, we have to figure-out what the mangled name is, and pass it on to dl_sym. This is unfriendly, particularly if you want to port the application to another platform where the mangling is different. One solution might be the availability of a mangling tool where the process is automated: given api inferface to the tool (much like the one present for demangler tools in most of the platforms), the mangling can be done as follows: foo = dl_sym(__mangle("unmangled human readable name")); // assumed that "char * __mangle (char *);" is implementation specific // and cannot be written portably Obviously, the mangling tool would need support from compiler because the tool needs "contextual" information (say, which might be required for mangling template related stuff) of the names that compiler obviously has. Or is it possible to make the contextual information "some-how" available to a stand-alone tool? I googled, but didn't find anything useful, so I wondering if such a tool is feasible and useful and if so, I am looking for inputs on constraints, issues and concerns in implementing such a tool. -Ganesh [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michaelangelo Guest Posted: Wed Aug 11, 2004 1:23 am    Post subject: Re: Implementing a mangling tool On 9 Aug 2004 16:54:19 -0400, [email]sgganesh (AT) gmail (DOT) com[/email] (Ganesh) wrote: Quote: Demanglers are widely used tools and very useful ones too, but are there any mangling tools? I would love to see this standardized. If not the naming convention, then at least the API (via a standardized lib function call.) Quote: I googled, but didn't find anything useful, so I wondering if such a tool is feasible and useful and if so, I am looking for inputs on constraints, issues and concerns in implementing such a tool. I seriously doubt this will ever get implemented though. It's a rare feature, that would depend on support for rebuilding a parse tree at run-time, when user-defined types are thrown in the mix. The compiler would need to store the name & sizeof() of every type in the executable, that was accessible at run-time. Still, it would be cool though to be able to enter a generic C/C++ function name, and convert it to a valid function pointer at run-time. (How do the debuggers (such as gdb) manage to do this?) Cheers [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ganesh Guest Posted: Wed Aug 11, 2004 7:47 pm    Post subject: Re: Implementing a mangling tool Michaelangelo <Michaelangelo (AT) email-will-be-ignored (DOT) com> wrote Quote: On 9 Aug 2004 16:54:19 -0400, [email]sgganesh (AT) gmail (DOT) com[/email] (Ganesh) wrote: Demanglers are widely used tools and very useful ones too, but are there any mangling tools? I would love to see this standardized. If not the naming convention, then at least the API (via a standardized lib function call.) Ah! Even the demangling API is not standardized (though specific schemes like Itanium ABI are there). Quote: I googled, but didn't find anything useful, so I wondering if such a tool is feasible and useful and if so, I am looking for inputs on constraints, issues and concerns in implementing such a tool. It's a rare feature, Is it really rare? I thought it would be useful in many cases, though not as useful as demanglers are. Quote: that would depend on support for rebuilding a parse tree at run-time, when user-defined types are thrown in the mix. The compiler would need to store the name & sizeof() of every type in the executable, that was accessible at run-time. For those with no requirement for context info, it won't be difficult, say, "operator new(unsigned long,void*)" which will be mangled as '_ZnwmPv' in IPF mangling. However, there are complexities - for those that require context info - for example, template instances it might be difficult but not impossible to do it if support is builtin in the compiler. Runtime information is not needed for any mangling. Quote: Still, it would be cool though to be able to enter a generic C/C++ function name, and convert it to a valid function pointer at run-time. Are you referring to the example I've given - its just an example and there are many uses for such a mangling tool. Quote: (How do the debuggers (such as gdb) manage to do this?) Tools such as gdb essentially do demangling and not mangling. -Ganesh [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Wed Aug 11, 2004 8:12 pm    Post subject: Re: Implementing a mangling tool Ganesh wrote: Quote: Demanglers are widely used tools and very useful ones too, but are there any mangling tools? Such a tool would be very useful in various cases; for example, foo = dl_sym("_implementation_specific_mangled_name"); In this case, we have to figure-out what the mangled name is, and pass it on to dl_sym. snip Why not declare the function extern "C" to avoid mangling? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michaelangelo Guest Posted: Thu Aug 12, 2004 12:08 pm    Post subject: Re: Implementing a mangling tool On 11 Aug 2004 16:12:00 -0400, Ben Hutchings <do-not-spam-benh (AT) bwsint (DOT) com> wrote: Quote: In this case, we have to figure-out what the mangled name is, and pass it on to dl_sym. snip Why not declare the function extern "C" to avoid mangling? Yes, that's one current work-around. But it doesn't work too well when you're trying to call C++ code written by others. You need to make you're using *exactly* the same compiler version, with the same settings. A little unrealistic. Peace -- How much C would a sea slug code if a sea slug could code C? - .sig seen on /. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michaelangelo Guest Posted: Thu Aug 12, 2004 12:08 pm    Post subject: Re: Implementing a mangling tool On 11 Aug 2004 15:47:21 -0400, [email]sgganesh (AT) gmail (DOT) com[/email] (Ganesh) wrote: Quote: Michaelangelo <Michaelangelo (AT) email-will-be-ignored (DOT) com> wrote On 9 Aug 2004 16:54:19 -0400, [email]sgganesh (AT) gmail (DOT) com[/email] (Ganesh) wrote: I googled, but didn't find anything useful, so I wondering if such a tool is feasible and useful and if so, I am looking for inputs on constraints, issues and concerns in implementing such a tool. It's a rare feature, Is it really rare? I thought it would be useful in many cases, though not as useful as demanglers are. I agree, *exteremly* usefull. I'm led to believe it's rare because... 1) What's the most common / popular type of C++ programming? I'd say it's more high-level, then low-level. 2) I haven't seen much talk/posts of people clammoring for it. But then I haven't looked much. Maybe you have more up-to-date info then me. It would be interesting in finding out who would be interested in it. I'm wondering if most people don't see the need for it, until they have seen a practical example that they can use in "everyday" coding? Take a look at templates... sure they were cool, but they didn't take off, until generic programming came into the scene. Quote: that would depend on support for rebuilding a parse tree at run-time, when user-defined types are thrown in the mix. The compiler would need to store the name & sizeof() of every type in the executable, that was accessible at run-time. For those with no requirement for context info, it won't be difficult, say, "operator new(unsigned long,void*)" which will be mangled as '_ZnwmPv' in IPF mangling. However, there are complexities - for those that require context info - for example, template instances it might be difficult but not impossible to do it if support is builtin in the compiler. Runtime information is not needed for any mangling. I agree, it should be doable & more importantly standarizable, for built-in types. So it looks like both udt, and templates are the monkey wrench. In the worst case, you're calling the compiler at run-time. Quote: Still, it would be cool though to be able to enter a generic C/C++ function name, and convert it to a valid function pointer at run-time. Are you referring to the example I've given - its just an example and there are many uses for such a mangling tool. (How do the debuggers (such as gdb) manage to do this?) Tools such as gdb essentially do demangling and not mangling. I thought they did mangling as well? i.e. You can type in a function name at run-time, and have it called. Or this only limited to pure "C" functions? I guess they could demangle all the functions, keeping track of the function address, and then do a table lookup on the unmangled name, instead of mangling the name. Peace [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Fri Aug 13, 2004 1:17 pm    Post subject: Re: Implementing a mangling tool Michaelangelo wrote: Quote: But it doesn't work too well when you're trying to call C++ code written by others. You need to make you're using *exactly* the same compiler version, with the same settings. A little unrealistic. On the contrary, you have it exactly backwards. If you do not use exactly the same compiler and settings, it is very likely that the modules will be incompatible with each other, and will cause crashes if you actually manage to get things linked. The mangling system protects you from error by being different for different implementations. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Wed Aug 18, 2004 6:38 pm    Post subject: Re: Implementing a mangling tool [email]sgganesh (AT) gmail (DOT) com[/email] (Ganesh) wrote Quote: Demanglers are widely used tools and very useful ones too, but are there any mangling tools? Such a tool would be very useful in various cases; for example, foo = dl_sym("_implementation_specific_mangled_name"); In this case, we have to figure-out what the mangled name is, and pass it on to dl_sym. This is unfriendly, particularly if you want to port the application to another platform where the mangling is different. If you're using dl_sym, you're already entering the territory of implementation-specific code. Using an implementation-specific "mangler" shouldn't be a problem -- if you ever do port your code, remember that you'll have to rewrite the "mangler" (among quite a few other sections of code, I'm sure). I've never needed a demangler myself, but if it's true that they are widely used, can you find one for your compiler that is also available in source code? If so, it ought to be simple to "reverse" the algorithm to produce your own mangler. If not, you may have to spend some time reverse-engineering the process -- but you can use the demangler to check your progress at any point. But there might be a better way. Set your project to create a "link map" and build your application. Then look at the map. Depending on your compiler and version, you'll at least get all of the mangled names to feed into your demangler, or maybe you'll even get both the mangled and straight names. Use this data as a const data structure; write a simple parallel-array lookup program, and you've got a mangler that works on any name needed in your program. Quote: One solution might be the availability of a mangling tool where the process is automated: given api inferface to the tool (much like the one present for demangler tools in most of the platforms), the mangling can be done as follows: You could probably write a code generator that reads the link map and writes out C++ code for function mangle. Then your makefile (or custom build step, or whatever your IDE calls it) would compile and link the entire program, run the code generator, re-compile function mangle, and re-link. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Wed Aug 18, 2004 6:40 pm    Post subject: Re: Implementing a mangling tool Quote: On 11 Aug 2004 16:12:00 -0400, Ben Hutchings wrote: In this case, we have to figure-out what the mangled name is, and pass it on to dl_sym. snip Why not declare the function extern "C" to avoid mangling? Michaelangelo <Michaelangelo (AT) email-will-be-ignored (DOT) com> wrote Quote: Yes, that's one current work-around. But it doesn't work too well when you're trying to call C++ code written by others. You need to make you're using *exactly* the same compiler version, with the same settings. A little unrealistic. Totally agree with Hyman Rosen's response, but I'd also like to point out: If your library code is trying to call C++ code written by others, *with arbitrary names*, you're putting the responsibility in the wrong place. The parameter that you should be getting is the mangled name, not the clear name. (Or perhaps both, if you need some human-readable name for some reason.) If dl_sym returns null, then display an error ("Entry point not found") and exit. This way, you could (at least in theory) even mix languages. Code in Fortran or assembly language doesn't use "mangled names" and so trying to mangle or demangle it can only lead to problems. Your library is extensible, because you can cause it to call functions in a third-party dynamic library. Yes, you want to make that as convenient as possible -- but no matter what you do, the writers of that third-party library have to have certain responsibilities. Obviously #1 on that list is giving you a way to determine the address to call. The fewer assumptions about how that works, the better. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.