Method for common marshaling between calls in/out of mono?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Method for common marshaling between calls in/out of mono?

Chase
For methods mono to c the method "mono_add_internal_call()" is provided, in
which variables are marshaled.
For methods c to mono we have "mono_method_get_unmanged_thunk()" is
provided, in which variables is not marshaled.

I've written a wrapper generator which aids in the process of binding the
languages.  Since handling variables changes depending on the direction of
the call it creates unwanted complexity in handling data types.  I'm
wondering if there is a method to make calls both ways that functioned the
same regardless of method, either marshaled or not.

I may have missed what I'm looking for in the documentation, please let me
know if I have.  If not I'd like to hear from someone familiar with the code
base on how difficult of an undertaking this might be for me to attempt to
add to the project.





--
View this message in context: http://mono.1490590.n4.nabble.com/Method-for-common-marshaling-between-calls-in-out-of-mono-tp4670291.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Method for common marshaling between calls in/out of mono?

Chase
I apologize as I used the term marshaling incorrectly here.  I used it as a
term to describe the differences in how certain objects specifically structs
are passed between the two methods.  As for internal calls, you receive a
pointer to memory of the struct, and thunks you pass a boxed mono object.



--
View this message in context: http://mono.1490590.n4.nabble.com/Method-for-common-marshaling-between-calls-in-out-of-mono-tp4670291p4670292.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Method for common marshaling between calls in/out of mono?

Jonathan Mitchell-2

> On 19 Mar 2017, at 22:34, Chase <[hidden email]> wrote:
>
> I apologize as I used the term marshaling incorrectly here.  I used it as a
> term to describe the differences in how certain objects specifically structs
> are passed between the two methods.  As for internal calls, you receive a
> pointer to memory of the struct, and thunks you pass a boxed mono object.
>
These API’s (not forgetting mono_runtime_invoke) do, as you say, use different calling conventions for their reference type arguments.
I don’t think that there is much to be done about this at the Mono run time level.

The thunking API is certainly simpler given that you just have to provide MonoObject *.

You could likely provide some helper functions that could query an exclusively  MonoObject * argument list and unbox reference types on the fly.

> I've written a wrapper generator which aids in the process of binding the
> languages.

Which language are you calling into the embedded API from?

In my own case my wrappers are produced a code generator which understands how to generate argument lists both for property thunking and for method invocation using mono_runtime_invoke.

Jonathan
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Method for common marshaling between calls in/out of mono?

Robert Jordan
In reply to this post by Chase
On 19.03.2017 23:02, Chase wrote:
> I may have missed what I'm looking for in the documentation, please let me
> know if I have.  If not I'd like to hear from someone familiar with the code
> base on how difficult of an undertaking this might be for me to attempt to
> add to the project.

The boxing of structs on thunk signatures is performed on purpose.
By the time the thunks were designed, there was no straightforward
way to mirror a managed struct declaration in C/C++ because of
unexpected alignment issues.

The canonical sample was

struct PointF {
        float x;
        float y;
}

whose fields got aligned at 8 bytes boundaries by Mono, while GCC
has aligned them at 4 bytes (i386 ABI).

Years later the alignment issue was removed, but the thunk APIs
remained unchanged for obvious reasons (compatibility).
This can be fixed, but it requires some decent knowledge
of Mono's runtime.

Another issue is returning structs from methods. This is usually
not compatible across CPUs and ABIs. Internal calls are avoiding
such signatures, and are returning values as an "out" argument
instead.

As there is no fix for this (AFAIK), thunks can't return unboxed
structs. mono_runtime_invoke doesn't either.

Robert


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Loading...