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

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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant