-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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: