[Mono] [swift-interop] Add support for reverse pinvoke argument lowering#104437
[Mono] [swift-interop] Add support for reverse pinvoke argument lowering#104437jkurdek merged 19 commits intodotnet:mainfrom
Conversation
3fc4be0 to
ad59f6d
Compare
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| MonoClass *swift_self = mono_class_try_get_swift_self_class (); | ||
| MonoClass *swift_error = mono_class_try_get_swift_error_class (); | ||
| MonoClass *swift_indirect_result = mono_class_try_get_swift_indirect_result_class (); | ||
| swift_lowering = g_newa (SwiftPhysicalLowering, sig->param_count); |
There was a problem hiding this comment.
Where are these deallocated?
There was a problem hiding this comment.
Good catch. Added deallocation for new_params. swift_lowering and swift_sig_to_csig_mp are allocated on stack, so we don't deallocate explicetely them right?
There was a problem hiding this comment.
Yes. Why they are allocated differently?
There was a problem hiding this comment.
swift_lowering and swift_sig_to_csig_mp are going to have exactly sig->param_count elements. In some places across marshalling code such arrays are allocated on stack.
swift_sig_to_csig_mp is an array of ints so I guess it ok. We could make the swift_lowering heap allocated, but I don't know whether this is necessary.
The new_params can be up to 4 times longer than theswift_lowering and swift_sig_to_csig_mp, as it includes the lowered params. So I following what was done in method-to-ir.
runtime/src/mono/mono/mini/method-to-ir.c
Line 7533 in f9eda07
src/mono/mono/metadata/marshal.c
Outdated
| } | ||
| } | ||
|
|
||
| csig = mono_metadata_signature_dup_new_params (NULL, NULL, get_method_image (method), csig, new_param_count, (MonoType**)new_params->data); |
There was a problem hiding this comment.
I'm unsure where we should allocate the new csig. For the direct p/invokes we allocate the temporary signature in mempool but I suppose this is not temporary so image is probably the right choice.
There was a problem hiding this comment.
yea, I also think image is the right place.
There was a problem hiding this comment.
hmm... actually... why not the mem manager of the method?
m_method_get_mem_manager (method). (That's usually the same as the image mempool, but for generic instances it will be the mempool of the whole set of images)
| tmp_locals [i] = mono_emit_marshal (m, csig_argnum, t, mspecs [i + 1], 0, &csig->params [csig_argnum], MARSHAL_ACTION_MANAGED_CONV_IN); | ||
| } else { | ||
| switch (t->type) { | ||
| case MONO_TYPE_VALUETYPE: |
There was a problem hiding this comment.
do you need a MONO_TYPE_GENERICINST case to handle SwiftSelf<T> or other generics?
There was a problem hiding this comment.
I believe currently we do not plan to support SwiftSelf<T> in reverse pinvokes #103576 (comment)
cc: @kotlarmilos
src/mono/mono/metadata/metadata.c
Outdated
| */ | ||
| MonoMethodSignature* | ||
| mono_metadata_signature_dup_new_params (MonoMemPool *mp, MonoMemoryManager *mem_manager, MonoMethodSignature *sig, uint32_t num_params, MonoType **new_params) | ||
| mono_metadata_signature_dup_new_params (MonoMemPool *mp, MonoMemoryManager *mem_manager, MonoImage *image, MonoMethodSignature *sig, uint32_t num_params, MonoType **new_params) |
There was a problem hiding this comment.
I think we should try to move away from passing MonoImage* to allocation functions. you can pass the mempool of the image if you need to. or better to get the mem manager for the method definition, I think.
There was a problem hiding this comment.
Reversed the change. Just for my education, why is passing MonoImage* a code smell?
lambdageek
left a comment
There was a problem hiding this comment.
mostly LGTM, but let's try to avoid adding a MonoImage* argument to the signature dup function. Using MonoImage* for allocation is a code smell.
Co-authored-by: Aleksey Kliger (λgeek) <[email protected]>
Adds support in Mono for passing Swift
@frozenstruct as arguments toUnmanagedCallersOnlycallbacks. Changes do not include support for lowering return value structs. That will come in separate PR. Detailed description of struct lowering can be found here #102143.Changes introduce struct lowering on IL level to
native-to-managedwrapper. First, the wrapper's signature is modified according to the result of struct lowering algorithm. For structs passed by reference we replace the struct arg with a reference arg. For a lowered struct, struct argument is replaced by a series of up to 4 primitive arguments.Then, during wrapper's IL code generation, additional code is emitted to load the new arguments at correct offsets.
Verified full AOT locally.
Contributes to #102077