Граф коммитов

13 Коммитов

Автор SHA1 Сообщение Дата
Rolf Bjarne Kvinge 0dee77cd83
[runtime] Deal with the rest of the Mono Embedding API for CoreCLR. (#11642)
* [runtime] Mark numerous Mono Embedding API as used only by the MonoVM bridge.

* [runtime] Exclude more unused code from the CoreCLR build.

* There's no tracing in CoreCLR, so no need to process the MONO_TRACE environment
  variable (and set the trace options).
* There's no sdb debuggger, so that code can be skipped.
* The profiler support is very different, so skip that code too.
* We don't support AOT, nor aot data files, so skip that.

* [runtime] Stop generating dummy implementations of the Mono Embedding API for CoreCLR.

All of the Mono Embedding API now falls in either of these two categories:

* Only used by the MonoVM bridge.
* Has a CoreCLR implementation.

Which means that we don't need the code to generate dummy implementations for
methods that aren't in any of these two categories anymore.
2021-05-21 07:53:41 +02:00
Rolf Bjarne Kvinge 7bc45c097a
[runtime] Don't start the toggle ref machinery in CoreCLR. (#10990)
The implementation will be completely different, where the hook into CoreCLR
is in managed code.

We still need to initialize the framework_peer_release_lock mutex, so move
that code out of gc_enable_new_refcount.
2021-03-30 18:06:23 -04:00
Rolf Bjarne Kvinge 18ac48c5c8 [runtime] Make it possible to implement Mono Embedding API in the CoreCLR bridge
By making it possible to skip the automatically generated Mono Embedding API that
just asserts.
2021-03-25 07:32:32 +01:00
Rolf Bjarne Kvinge c406cc1da7
[runtime] Don't install any logging/printing handlers for CoreCLR, there's no equivalent. (#10927)
This also means that we don't have to generate CoreCLR wrappers for the corresponding
embedding API, so adjust the generated code accordingly.
2021-03-22 15:18:37 +01:00
Rolf Bjarne Kvinge d778cc28c8
[runtime/dotnet] Call coreclr_initialize/monovm_initialize at startup. (#10909)
We need to call coreclr_initialize/monovm_initialize at startup, so do that.
This is a partial implementation, in that we're not setting all the properties
that we should, and also the PINVOKE_OVERRIDE callback is not doing everything
it should either yet.

Ref: #10504.
2021-03-22 08:04:56 +01:00
Rolf Bjarne Kvinge 4e0978e46c
[runtime] Link the CoreCLR version of libxamarin with CoreCLR instead of Mono. (#10853)
* [runtime] Link the coreclr version of libxamarin with CoreCLR instead of Mono.

The diff might look a bit weird, because there's no changes specific to CoreCLR -
the difference is that we're in fact removing a special-case to link with Mono: we
used the DOTNET_$(rid)_LIBDIR variable to specify the directory where to find libcoreclr,
we now use DOTNET_CORECLR_$(rid)_LIBDIR when building for CoreCLR, but that's handled
by the default case, so no need to add any special casing. We still override DOTNET_osx-<arch>_LIBDIR
for MonoVM (no change needed for that).

* [runtime] Generate stubs for the mono embedding API when building for CoreCLR.

This makes libxamarin link successfully when building for CoreCLR.
2021-03-12 18:40:48 +01:00
Sebastien Pouliot f9aa25cefa
[runtime] Replace custom string concatenation inside `mono-runtime.m.t4` (#8865)
by simpler, at least to review, ObjC code.
2020-06-16 13:26:58 -04:00
Rolf Bjarne Kvinge 02fe5339a4
[runtime] Clean up public symbols. Fixes #5124. (#5155)
* [runtime] Clean up public symbols. Fixes #5124.

Clean up public symbols, by:

* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
  handle in the test.

This minimizes the chance of getting into a symbol clash with another native library.

Fixes https://github.com/xamarin/xamarin-macios/issues/5124.

* Some test fixes.
2018-11-21 11:48:15 -05:00
Rolf Bjarne Kvinge 41da2d1e28
[runtime] Use public mono API to set the pending exception. Fixes #4271. (#4272)
This makes exception marshaling work with Xamarin.Mac apps that use the system
mono (such as Visual Studio for Mac, and assuming at least a v5.12 system
mono).

https://github.com/xamarin/xamarin-macios/issues/4271
2018-06-15 23:45:02 +02:00
Rolf Bjarne Kvinge ac45813621 [runtime] Call mono_raise_exception if mono_set_pending_exception isn't available. Works around bug #59979 (#2845)
mono_set_pending_exception is a private mono symbol, which means we won't find
it when using the system mono (as a dynamic library). In that case, we'd
abort.

Instead try to call mono_raise_exception, and hope for the best. It will leak
somewhat, but that's still better than asserting.

This changes the generated wrapper function from:

```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
	if (mono_set_pending_exception_func == NULL)
		xamarin_assertion_message ("Could not load mono_set_pending_exception\n");

	return mono_set_pending_exception_func (exc);
}
```

to

```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
	if (mono_set_pending_exception_func == NULL)
		return mono_raise_exception (exc);

	return mono_set_pending_exception_func (exc);
}
```

Also this only applies to Xamarin.Mac apps that use the system mono (such as VSfM).

https://bugzilla.xamarin.com/show_bug.cgi?id=59979
2017-10-05 18:13:44 +02:00
Rolf Bjarne Kvinge fb463ed921 [registrar] Don't require private mono symbols for BindAs support.
The two functions mono_class_is_nullable and mono_class_get_nullable_param are
private mono symbols, which means we can't call them when using Xamarin.Mac
with libmono from a dynamic library.

Implement a fallback for this case, where we call a managed method when these
functions are not available (and restrict this workaround to Xamarin.Mac only,
since it's not needed for Xamarin.iOS).
2017-07-04 18:33:32 +02:00
Rolf Bjarne Kvinge cfb84f6e17 [runtime] Use printf on watchOS, NSLog doesn't shown up (by default) (#772)
* [runtime] Use printf on watchOS, NSLog doesn't shown up (by default).

* [runtime] Use a wrapper function for logging.

So that we can chose between printf and NSLog at runtime,
depending on where we're running.
2016-09-06 16:55:23 -04:00
Rolf Bjarne Kvinge ac418df815 Build our runtime. 2016-04-24 14:47:24 -04:00