-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Undecorate functions from C++ compilers #3
Comments
well, I think for a C functions (and C++ if used C linkage), it should be solved simply: Since more than one overloaded function is not possible at all: Compiler Error C2733 - https://msdn.microsoft.com/en-us/library/5z9es6ec.aspx LIBAPI unsigned short int __stdcall get_SevenStdCall(); // _get_SevenStdCall@0
LIBAPI unsigned short int __stdcall get_SevenStdCall(int a); // _get_SevenStdCall@4 we can try to get list of all exported functions from dll, and finally get __fastcall: @get_SevenFastCall@0
__vectorcall: get_SevenVectorCall@@0 but C++ mangling still TODO =/ |
…of exported functions /#3 also fixed bug when updating CallingConvention for DLR +IConfig.Mangling +IBinder.bind(MethodInfo mi, string name, CallingConvention conv) and splitting of DLR property for additional __cdecl, __stdcall, __fastcall, __vectorcall calling convention
now, Conari will do it all automatically for C functions, e.g.: dlr.get_SevenStdCall<ushort>() //-> _get_SevenStdCall@0
dlr.get_SevenFastCall<ushort>() //-> @get_SevenFastCall@0 done. :p C++ later... |
NEW: DLR features for core with caching of dynamic types. NEW: Added features for convenient work with Native C/C++ structures without declaration. /Issue #2 NEW: The Mangling features by C rules: to automatically find entry points of exported functions. /Issue #3 NEW: Added access to export functions from PE files. ILoader.ExportFunctionNames NEW: Added LSender as a simple retranslator for loggers. NEW: Added features for convenient work with any binary raw data. NEW: Added Core events: * BeforeUnload - Before unloading a library. * AfterUnload - When library has been unloaded. * AfterLoad - When library has been loaded. * PrefixChanged - When Prefix has been changed. * ConventionChanged - When Convention has been changed. FIXED: bug with CharPtr when unboxing for unmanaged code. FIXED: trivial fixes with implicit conversion for size_t and UIntPtr. CHANGED: Updated CharPtr: +BSTR, +WCharPtr & added new UnmanagedString, that allocates strings for unmanaged code. CHANGED: Other trivial fixes and improvements.
the develop branch is already contains DLR features, but it's not possible for exported functions from C++ compiler.
i.e.:
thus we can't use this like
l->?getSeven@API@UnLib@Conari@r_eg@net@@YAGXZ()
even if it's possible, it is... omg :)Currently, we can also use a standard
bind
methods, like:but it still not useful at all :)
For C++ compiler we can simply tell: export it, as it would be for C compiler i.e.
extern "C" __declspec(dllexport)
but of course, this should be from third party code.. so, what to do:
The main problem: the same functions cannot be same from different compilers :(
TODO: just to find already existing solution for mangling names
Then we should provide support for example:
If user wants to call this:
net::r_eg::Conari::UnLib::API::getSeven(void)
Decoration for a C functions (and C++ if used C linkage):
In a 64-bit environment, functions are not decorated.
The text was updated successfully, but these errors were encountered: