Export monovm_create_delegate

[raulsntos]

monovm_create_delegate was missing MONO_API, without it the symbol can't be found with dlsym.

For context, MONO_API was deemed not needed at the time of adding the API¹. However, I'm interested in using this API directly instead of going through coreclr_create_delegate for a Mono host implementation I'm working on.

Footnotes

1. https://github.com/dotnet/runtime/pull/59962#discussion_r721646839 ↩

[huoyaoyuan]

It's public API and needs approval, though I'm not sure the process for hosting API.

However, I'm interested in using this API directly instead of going through coreclr_create_delegate for a Mono host implementation I'm working on.

What's the problem with coreclr_create_delegate?

[raulsntos]

Since I'm using the Mono runtime, it feels weird having to use an API with the coreclr prefix. I know the CoreCLR APIs will be available in libmonosgen-2.0.so but it's not very intuitive, and I'm not sure it's a guarantee I can rely on in the future.

coreclr_create_delegate also has more parameters that are unused for Mono (hostHandle and domainId), but you won't know that unless you look at the implementation.

And as you can see in monovm.h, similar Mono hosting APIs that have equivalent CoreCLR hosting APIs are already exported. For example, in libmonosgen-2.0.so there's both coreclr_execute_assembly and monovm_execute_assembly.

[lambdageek]

I don't think we should make it public. This is an implementation detail of mono's support for the coreclr hosting API.

[jkotas]

Since I'm using the Mono runtime, it feels weird having to use an API with the coreclr prefix.

Mono uses CoreCLR names in number of places. For example, the Mono VM binary name is libcoreclr.so in some build configurations. It was a shortcut that we took during the initial integration of Mono into dotnet/runtime and we did not have a chance to go back to clean it up.

We want the public surface of Mono and CoreCLR to be the same.

[raulsntos]

We want the public surface of Mono and CoreCLR to be the same.

Then why bother exposing monovm_execute_assembly, monovm_shutdown, and monovm_initialize? When there's already coreclr_execute_assembly, coreclr_shutdown, and coreclr_initialize. It seems inconsistent to me. Is this a new policy going forward that wasn't in place when those other APIs were exposed? And what's the recommendation for consumers?

Is it OK to use coreclr_create_delegate when hosting the Mono runtime? I was under the impression it's not recommended, even though it's accessible from libmonosgen-2.0.so. Can you confirm that coreclr_create_delegate is safe to use and will not be removed in the future from libmonosgen-2.0.so?

[jkotas]

why bother exposing monovm_execute_assembly, monovm_shutdown, and monovm_initialize?

@lambdageek Do you happen to know why these got exposed? Are they still used?

[lambdageek]

From #32136

The monovm header functions are exported for testing purposes, but the file is intentionally not made public as of now.

I don't actually recall any tests that exercised these directly. Maybe we had something in mono/mono...

[raulsntos]

I see monovm_initialize used in https://github.com/lambdageek/monovm-embed-sample/blob/c35f945509b0d1e4f4412a7076c9e769708c3ff1/src/native/main.c#L60, although the repo's README does say:

WARNING This code is EXPERIMENTAL and not supported.

I also see some monovm functions used in dotnet/android:

• monovm_initialize_preparsed in https://github.com/dotnet/android/blob/932113927d217d8d9dbc3db029f75ae3426c303e/src/native/monodroid/monodroid-glue.cc#L1388-L1393
• monovm_runtimeconfig_initialize in https://github.com/dotnet/android/blob/932113927d217d8d9dbc3db029f75ae3426c303e/src/native/monodroid/monodroid-glue.cc#L709

What I don't see is any coreclr function used in those repos.

There's also some monovm functions used in xamarin/xamarin-macios for the monovm-bridge:

• monovm_initialize in https://github.com/xamarin/xamarin-macios/blob/0edba0ea680c570515cbabb05d90816a0f999db9/runtime/monovm-bridge.m#L466
• monovm_runtimeconfig_initialize in https://github.com/xamarin/xamarin-macios/blob/0edba0ea680c570515cbabb05d90816a0f999db9/runtime/monovm-bridge.m#L450

The only coreclr functions used in this repo seem to be in the coreclr-bridge.

And then, in the dotnet/runtime repo the monovm_initialize and monovm_runtimeconfig_initialize functions are also used in the Browser driver, WASI driver, AndroidAppBuilder, and LibraryBuilder. None of those seem to use any coreclr functions.