Skip to content
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

Open
3F opened this issue Aug 12, 2016 · 2 comments
Open

Undecorate functions from C++ compilers #3

3F opened this issue Aug 12, 2016 · 2 comments

Comments

@3F
Copy link
Owner

3F commented Aug 12, 2016

the develop branch is already contains DLR features, but it's not possible for exported functions from C++ compiler.

i.e.:

#define LIBAPI_CPP  __declspec(dllexport) // will decorated like: ?getSeven@API@UnLib@Conari@r_eg@net@@YAGXZ
                                          // e.g.: unsigned short net::r_eg::Conari::UnLib::API::getSeven(void)
#define LIBAPI  extern "C" __declspec(dllexport) // will undecorated like from C compiler: getSeven()

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:

l.bind<Func<ushort>>("?getD_Seven@API@UnLib@Conari@r_eg@net@@YAGXZ")();

// or

l.bind(Dynamic.GetMethodInfo(typeof(ushort)), "?getD_Seven@API@UnLib@Conari@r_eg@net@@YAGXZ")
                 .dynamic
                 .Invoke(null, new object[0]);

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)

l.Mangling  = true; // switch of decoration
l.Prefix    = "net::r_eg::Conari::UnLib::API::"; //for all other functions

ushort val  = dll.getSeven<ushort>();  // to call unsigned short getD_Seven(void)
// before calling we should get final name: ?getD_Seven@API@UnLib@Conari@r_eg@net@@YAGXZ
// then simply call

Decoration for a C functions (and C++ if used C linkage):

In a 64-bit environment, functions are not decorated.

- -
__cdecl Underscore character (_) is prefixed to names, except when __cdecl functions that use C linkage are exported.
__stdcall Leading underscore (_) and a trailing at sign (@) followed by the number of bytes in the parameter list in decimal
__fastcall Leading and trailing at signs (@) followed by a decimal number representing the number of bytes in the parameter list
__vectorcall Two trailing at signs (@@) followed by a decimal number of bytes in the parameter list
@3F 3F added the enhancement label Aug 12, 2016
@3F
Copy link
Owner Author

3F commented Aug 13, 2016

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
error C2733: '...': second C linkage of overloaded function not allowed

    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 _get_SevenStdCall@4 or _get_SevenStdCall@0, etc. :)

__fastcall:   @get_SevenFastCall@0
__vectorcall: get_SevenVectorCall@@0

but C++ mangling still TODO =/

3F added a commit that referenced this issue Aug 16, 2016
3F added a commit that referenced this issue Aug 16, 2016
…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
@3F
Copy link
Owner Author

3F commented Aug 16, 2016

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...

3F added a commit that referenced this issue Aug 17, 2016
    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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant