Defining xm_nint_t to be 32-bit sized only on i386 is not the right thing to do for armv7.
Strangely enough this caused just a single test failure:
MonoTouchFixtures.Foundation.CalendarTest
[FAIL] TestFindNextDateAfterDateMatching : Expected: <Foundation.MonoTouchException>
But was: null
at MonoTouchFixtures.Foundation.CalendarTest.TestFindNextDateAfterDateMatching()
and that happened because:
1. We use a wrapper function around objc_msgSend:
void *
xamarin_IntPtr_objc_msgSend_IntPtr_IntPtr_nuint_exception (id self, SEL sel, void * p0, void * p1, xm_nuint_t p2, GCHandle *exception_gchandle)
{
@try {
return ((func_xamarin_IntPtr_objc_msgSend_IntPtr_IntPtr_nuint_exception) objc_msgSend) (self, sel, p0, p1, p2);
} @catch (NSException *e) {
xamarin_process_nsexception_using_mode (e, true, exception_gchandle);
return NULL;
}
}
2. Note that the second to last argument is an 'xm_nuint_t'. We told the
native compiler this was a 64-bit value, when the managed P/Invoke would
give it a 32-bit value. This had no effect on the 'p2' parameter, but it
meant that clang would thing the next argument, 'exception_gchandle', would
be somewhere it wasn't (the managed function would pass two 32-bit values,
'p2' and 'exception_gchandle', which clang would merge into a single 64-bit
'p2' argument, and then read random stuff for 'exception_gchandle').
3. Finally things would go sideways when we caught the exception and passed
'exception_gchandle' to xamarin_process_nsexception_using_mode. In effect
we'd ask xamarin_process_nsexception_using_mode to store the resulting
gchandle in random memory. Amazingly it only resulted in a test failure
(because upon return the managed location for the 'exception_gchandle'
wasn't touched, and would have its initial value of 0, thus managed code
would think no exception occurred).
So fix this to use the correct underlying types, instead of trying to figure
out the correct #if condition.
I'm not sure why we're using our own types here anyways, but this fix is the
smallest.
Instead of generating one native P/Invoke signature with an int parameter and
another with a long parameter for methods that take [Native] enums, generate a
single nint parameter (and the same for the unsigned version).
This simplifies both the generator code and the generated code. The generator
diff contains *a lot* of changes like this:
- if (IntPtr.Size == 8) {
- ret = (ARAppClipCodeUrlDecodingState) global::ObjCRuntime.Messaging.Int64_objc_msgSend (this.Handle, Selector.GetHandle ("urlDecodingState"));
- } else {
- ret = (ARAppClipCodeUrlDecodingState) global::ObjCRuntime.Messaging.int_objc_msgSend (this.Handle, Selector.GetHandle ("urlDecodingState"));
- }
+ ret = (ARKit.ARAppClipCodeUrlDecodingState) (long) global::ObjCRuntime.Messaging.nint_objc_msgSend (this.Handle, Selector.GetHandle ("urlDecodingState"));
An unlinked Xamarin.iOS.dll is ~300kb smaller (once linked the difference
should be minimal though).
I also made the min/max detection logic (check for int32.MinValue/MaxValue and
convert to int64.MinValue/MaxValue) specific to ARCH_32, since we don't need
it in 64-bit code.
Setting the XAMARIN_LOG_MARSHALLED_EXCEPTIONS environment variable will now
make us print all exceptions that go through exception marshalling, and how
we'll handle them.
Fixes https://github.com/xamarin/xamarin-macios/issues/12343.
* Add support for Mono Components.
* Modify how we look up symbols from native libraries shipped with Mono: we keep
track of which native libraries we linked with, and depending on how we linked
to those assemblies, we look the symbols up at runtime in either the current executable
(if linking statically), or the actual library (where the P/Invoke says they're
supposed to be).
* This means that we have to propagate how libmono is linked from the MSBuild code
to the Application class so that our existing logic is able to correctly determine
which native mono lib to use.
* Modify how we list the P/Invokes we need to preserve by taking into account the
list of native libraries from Mono we have to link with (for .NET). For legacy
Xamarin, I've reverted the logic to how it was before we started adding .NET support.
Fixes https://github.com/xamarin/xamarin-macios/issues/10950.
Fixes https://github.com/xamarin/xamarin-macios/issues/11145.
Fixes https://github.com/xamarin/xamarin-macios/issues/12100.
List all the assemblies in the app bundle and pass them to MonoVM/CoreCLR's in
the TRUSTED_PLATFORM_ASSEMBLIES initialization property.
This way CoreCLR knows where to find System.Private.CoreLib.dll for fat apps
(it's in the runtimeidentifier-specific subdirectory, and by default CoreCLR
will only look next to libcoreclr.dylib).
Fixes https://github.com/xamarin/xamarin-macios/issues/12265.
This also meant propagating how libmono is linked from the MSBuild code to the Application
class so that our existing logic is able to correctly determine which native mono
lib to use.
We need to process the runtimeconfig.json file somehow when using CoreCLR, and
the embedding API we use (coreclr_initialize) won't parse it for us. So re-use
the logic we already have to process runtimeconfig.json for MonoVM (which
involves converting it to a binary format at build time, which we then process
at runtime).
* Use the Apple-provided TARGET_OS_SIMULATOR define to determine if we're
running in a simulator, instead of checking the current architecture. This
way we properly detect ARM64-based simulators (and it'll work correctly in
the future).
* Always set Runtime.Arch = SIMULATOR for Mac Catalyst. The final value for
Runtime.Arch for Mac Catalyst is tracked in #10312, but this is a stop-gap
measure to make sure we have the same value between X64 and ARM64 on Mac
Catalyst, and until now we've had Runtime.Arch = SIMULATOR for X64, so just
go with that for now.
Return early when we're not going to try resolving anything, which means that
if we didn't find something by the end, we know that it's because we failed
(and not because we weren't supposed to try), and we log that.
This makes it easier to diagnose a few failure conditions.
To have consistent behavior in .NET, set the current directory to the root of
the app bundle for all platforms.
This is a breaking change for legacy Xamarin.Mac, which used to set the
current directory to the Contents/Resources subdirectory, but there's a simple
workaround for customers that depend on the old behavior (change it in Main
themselves), and I believe the consistent experience across platforms warrants
this change.
Note that we already had a breaking change here for macOS/.NET: we were
(unintentionally) setting the current directory to the Contents/MonoBundle
directory, which neither matched mobile platforms, nor the legacy Xamarin.Mac
behavior.
This solves the problem of what to do for Mac Catalyst apps, because there's
no need to choose between the macOS or the mobile behavior, since they're the
same.
This required changing the launch of macOS apps using CoreCLR to pass the full
path to the entry assembly, since the entry assembly isn't in the current
directory anymore.
The code contains comments explaining the new behavior.
Some tests that poked into the private 'flags' field on NSObject had to be
updated, because the field is now named differently in .NET.
I also added two more tests for toggle ref scenarios.
No more leaks!
Before:
There were 205834 MonoObjects created, 205834 MonoObjects freed, so no leaked MonoObjects. (static registrar)
There were 258092 MonoObjects created, 258013 MonoObjects freed, so 79 were not freed. (dynamic registrar)
After:
✅ There were 205834 MonoObjects created, 205834 MonoObjects freed, so no leaked MonoObjects. (static registrar)
✅ There were 258100 MonoObjects created, 258100 MonoObjects freed, so no leaked MonoObjects. (dynamic registrar)
Before:
There were 258096 MonoObjects created, 246948 MonoObjects freed, so 11148 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205214 MonoObjects freed, so 620 were not freed. (static registrar)
After:
There were 205834 MonoObjects created, 205222 MonoObjects freed, so 612 were not freed. (dynamic registrar)
There were 258100 MonoObjects created, 258019 MonoObjects freed, so 81 were not freed. (static registrar)
* If the return value from xamarin_get_reflection_method_method is cached in a
static variable, we can only release at process exist.
* Otherwise just release at the end of the current method.
Before:
There were 258096 MonoObjects created, 246948 MonoObjects freed, so 11148 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205214 MonoObjects freed, so 620 were not freed. (static registrar)
After:
There were 258092 MonoObjects created, 246945 MonoObjects freed, so 11147 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205600 MonoObjects freed, so 234 were not freed. (static registrar)
While not strictly necessary to not leak (because the process is exiting
anyway), it makes it easier to read leak reports, because these dictionaries
won't show up as leaked memory anymore.
Before:
There were 258096 MonoObjects created, 258015 MonoObjects freed, so 81 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205833 MonoObjects freed, so 1 were not freed. (static registrar)
After:
There were 258104 MonoObjects created, 258025 MonoObjects freed, so 79 were not freed. (dynamic registrar)
There were 205834 MonoObjects created, 205834 MonoObjects freed, so no leaked MonoObjects. (static registrar)
* [runtime] Add support for exception marshalling to CoreCLR.
* [runtime] Add an empty implementation of the toggle ref machinery.
We need this to use the unhandled exception handler support in CoreCLR,
because the ObjectiveCMarshal.Initialize call to initialize unhandled
exception support requires passing toggle ref callbacks as well.
* [tests] The TestConstrainedGenericType test can now be re-enabled, after a few updates.
Before:
There were 258042 MonoObjects created, 235166 MonoObjects freed, so 22876 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204219 MonoObjects freed, so 1585 were not freed. (static registrar)
After:
There were 258066 MonoObjects created, 246781 MonoObjects freed, so 11285 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204491 MonoObjects freed, so 1313 were not freed. (static registrar)
Before:
There were 258042 MonoObjects created, 235166 MonoObjects freed, so 22876 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204219 MonoObjects freed, so 1585 were not freed. (static registrar)
After:
There were 258050 MonoObjects created, 235177 MonoObjects freed, so 22873 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204219 MonoObjects freed, so 1585 were not freed. (static registrar)
Before:
There were 258042 MonoObjects created, 235166 MonoObjects freed, so 22876 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204219 MonoObjects freed, so 1585 were not freed. (static registrar)
After:
There were 258058 MonoObjects created, 235308 MonoObjects freed, so 22750 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204219 MonoObjects freed, so 1585 were not freed. (static registrar)
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258054 MonoObjects created, 235172 MonoObjects freed, so 22882 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 205190 MonoObjects freed, so 614 were not freed. (static registrar)
Before:
There were 258046 MonoObjects created, 235142 MonoObjects freed, so 22904 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
After:
There were 258054 MonoObjects created, 235172 MonoObjects freed, so 22882 were not freed. (dynamic registrar)
There were 205804 MonoObjects created, 204193 MonoObjects freed, so 1611 were not freed. (static registrar)
Due to the following reasons:
* Desktop apps like macOS and Mac catalyst can be launched directly from the
command line by users.
* It's trivial to set environment variables for desktop apps before launching
them.
* All the different command line arguments we support for mobile targets can
also be set using environment variables.
We don't need additional command line argument parsing for desktop platforms,
so just remove it.
The end result is that instead of doing this to run a specific unit test:
path/to/macOS/app/MacOS/Contents/theapp --app-arg --test --app-arg MyTestFixture
This will now work:
path/to/macOS/app/MacOS/Contents/theapp --test MyTestFixture
Which is how apps on desktop platforms should work anyway.
Before:
There were 257927 MonoObjects created, 144942 MonoObjects freed, so 112985 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 113865 MonoObjects freed, so 91835 were not freed. (static registrar)
After:
There were 257931 MonoObjects created, 235062 MonoObjects freed, so 22869 were not freed. (dynamic registrar)
There were 205700 MonoObjects created, 203983 MonoObjects freed, so 1717 were not freed. (static registrar)
The workaround doesn't work anymore anyway, this is printed on every launch:
> MonoTouch: Could not install sigaction override, unexpected sigaction implementation.
Ref: 054bbdce96
* [runtime] Add support for tracking created and destroyed MonoObject* instances for CoreCLR.
Implement a rudimentary way of tracking created and destroyed MonoObject*
instances, so that it's easy to find leaks.
* Add a xamarin_bridge_shutdown method that's called just before returning from xamarin_main.
And use it to dump the leaked MonoObject*s.
* [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.
The native xamarin_bridge_get_method_declaring_type method and the
corresponding managed method (GetMethodDeclaringType) takes and returns a
MonoObject*, not a GCHandle.
Due to the wonders of void pointers, this worked just fine before - there's no
actual change to the compiled code - but the code is now more consistent and
less confusing.
The value should never be used if everything is working fine, but if something
is wrong, then this value will at least get consistent behavior.
The visible result for us right now is that monotouch-test will fail with a
test failure instead of crashing.
CoreCLR is being added for macOS only. We can eliminate a lot of recent
code additions (about half a megabyte in the past week) by eliminate code
branches under `if (IsCoreCLR)`.
Unlike handling (non required at runtime) custom attributes the
`ILLink.Substitutions.xml` will vary quite a bit across platforms so we
use a unique file for each platform.
* Remove a few unused xamarin_get_*_class functions.
* Make the remaining two (xamarin_get_[nsnumber|nsvalue]_type) return a
MonoType* instead of MonoClass* - that makes things slightly simpler for
CoreCLR (the MonoClass* return values from the previous functions were
always converted to MonoType*s anyway).
* Implement the xamarin_get_[nsnumber|nsvalue]_type functions.
* Make the existing mono_get_string_class use the new (and more generic)
xamarin_bridge_lookup_class method instead of the specific
xamarin_bridge_get_string_class (which can now be removed).
* Make 'throw Objective-C exception' the default for managed exception marshalling.
* Make 'throw managed exception' the default for Objective-C exception marshalling.
* Disallow the 'unwind through native frames' option: CoreCLR won't do it.
* Disallow the 'unwind through managed frames' option: it's the safeset
option by far, and also matches the reverse case.
* Disallow the 'disable' option: this is also not safe, let's try to go the
safe route with CoreCLR.
* Change the default in native code too.
Partial fix for #10940.
This makes it easier for CoreCLR. Also, at least for CoreCLR, it's unlikely to
be slower, since we'd have to compute the MONO_TYPE_* value in any
compatibility function.
Passing a 'MonoObject*' to a function that expects a GCHandle doesn't quite
work, so make sure to get a GCHandle for the exception we want to print
information about.
We need additional API in CoreCLR to support pending exception properly, and
this is in progress [1]. In the meantime, stub out parts of it, so that the
process doesn't abort. This way we'll have failing tests instead (and work in
other areas can progress, since the process doesn't abort).
[1]: https://github.com/dotnet/runtime/pull/52146
This is not the fastest implementation, but it's the simplest I could come up
with, with the target of sharing as much code as possible with MonoVM. It can
be improved later if we find out it's a slow path (these functions are not in
a common code path, very few API bindings end up here).
* Implement our xamarin_dyn_objc_msgSend[Super] overrides for ARM64.
* Modify mmp to use those overrides.
* Fix an issue with the existing xamarin_arm64_common_trampoline that caused
exceptions to not unwind correctly.
* Add an ARM64 variation of xammac tests in xharness.
* Various test fixes.
Also add Call Frame Information (CFI) / Canonical Frame Address (CFA) directives.
This is required for native exceptions to work properly (otherwise the native runtime
won’t be able to unwind stack frames correctly).
When using the MonoVM, we compare MonoClass instances by pointer. This turns
out a bit complicated for CoreCLR, because our MonoClass instances are not
unique (there can be multiple MonoClass instances that refer to the same
type), so instead implement helper methods that do the comparison. This also
has the benefit of not requiring any memory allocations on CoreCLR.
There's no general way to set a pending managed exception in CoreCLR (the
current plan is to support setting a pending managed exception for the
objc_msgSend family of functions). This means that the way we've implemented
custom wrappers that can handle Objective-C exceptions won't work, because
those wrappers currently tries to set a pending managed exception (which Mono
throws upon returning from the corresponding native wrapper function).
So rewrite this a bit: these custom wrappers now return a GCHandle with the
managed exception as an out parameter, and the calling managed code throws
that exception instead.
This also required adjusting a few API definitions to match how their wrapper
functions are defined.
* [runtime] Call into managed code to handle runtime exceptions.
This makes things easier for CoreCLR.
There should be no significant performance hits; this code path is
exceptional, and exceptions are already very heavy-weight anyways.
* Update to use xamarin_free instead of mono_free as per review.
* Port more to managed code.
* The generated static registration code will eventually be different.
* The generated code has to be compiled with different compiler flags.
This also required adding a new overload of xamarin_mono_object_release for the generated
code to compile.
This also meant reviewing calling code to make sure that MonoObject*s are
released when they should be, which meant reviewing every method that returns
a MonoObject*, and release the result.
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
* monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the xamarinSetGCHandle🎏 / xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
* xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
This required adding a helper method to get the assembly name for a given
MonoAssembly, since that's what CoreCLR uses to determine what to execute.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Update dependencies from https://github.com/dotnet/installer build 20210408.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21208.1
* Update dependencies from https://github.com/dotnet/installer build 20210409.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21209.4
* Update dependencies from https://github.com/dotnet/installer build 20210410.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21210.1
* same P4 specific fix as ccb43cba56
but the ICU support was added based on P3 but merged after ^
* Update dependencies from https://github.com/dotnet/installer build 20210412.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21212.5
* Update dependencies from https://github.com/dotnet/installer build 20210413.70
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21213.70
* Update dependencies from https://github.com/dotnet/installer build 20210414.14
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21214.14
* Update to new package names
Thanks @pjcollins for the heads up https://github.com/xamarin/xamarin-macios/pull/11175#issuecomment-819936692
* Update dependencies from https://github.com/dotnet/installer build 20210415.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.1
* Fix build (path changed to include '.mono')
* remove more '.mono' special case that are not needed anymore
* Update dependencies from https://github.com/dotnet/installer build 20210415.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.12
* Fix building apps (it now finds the native libs)
Credits to @filipnavara
8325f8dadc
* Add back IsTrimmable (or nothing gets linked)
* Update dependencies from https://github.com/dotnet/installer build 20210418.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21218.6
* Keep downloading the CoreCLR runtime packs.
* [runtime] Adjust the build to link with the correct runtime library for CoreCLR.
* [tests][monotouch-test] Ignore NSTimeZoneTest / All_28300 on dotnet as it hangs
Introduced with https://github.com/dotnet/runtime/pull/48931
Issue https://unicode-org.atlassian.net/browse/ICU-21591
PR https://github.com/unicode-org/icu/pull/1699
* [dotnet][msbuild] Add more (missing) '\'
Fix satellite/location assemblies and some unit tests
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
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.
Those are called respectively inside `xamarin_vm_initialize` and
`xamarin_bridge_initialize` functions.
This fix the **AppContext.GetData always return null for iOS** issue
https://github.com/dotnet/runtime/issues/50290
Thanks for @filipnavara for diagnosing this quicker than anyone else!
Added unit tests to ensure `AppContext.GetData` can read back the values
we're providing at startup.
We need a way to represent a managed object in native code, and since most our existing
runtime code uses MonoObjects, we use the same for the CoreCLR bridge, just our own
version of it. In Mono, the MonoObjects are tracked by the GC (which scans the stack),
but we can't make CoreCLR scan the stack, so we use a reference counted version of
MonoObject instead - we just put the GCHandle into a reference counted MonoObject,
and when the MonoObject is freed, then we free the GCHandle as well.
* Move the existing logic to call Runtime.Initialize into the MonoVM code.
* Implement calling the managed Runtime.Initialize method from the CoreCLR bridge.
The call to Runtime.Initialize succeeds, which means we're now executing
managed code with CoreCLR for the first time.
The fields of the MonoObject struct is specific to MonoVM, so this makes sure
we don't accidentally poke into random memory on CoreCLR.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
If no exception handling is provided when calling a managed delegate from native
code, and the managed code throws, then we'll abort.
It's not entirely clear how we'll handle managed exceptions that go through native
code yet, so this makes the initial implementation easier. By making the exception
handling optional, it'll be easy to find all cases where we need to fix it later,
by making it non-optional. The alternative is to add exception handling code all
over the place that would potentially have to be updated when we figure out exactly
what needs to be done.
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.
* [runtime] Download the CoreCLR embedding header file
* [runtime] Create VM-specific code and header files and include them in the build
* [runtime] Move MonoVM-specific initialization to MonoVM-specific code.
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
Move the creation of an uninitialized NSObject from native to managed, which:
* Removes the need for the mono_object_new Embedding API.
* Removes one location where we write to managed memory from native code (to
write the handle + flags in the uninitialized NSObject).
* Makes things easier for CoreCLR.
* We already switch to GC Safe mode anyway, so there were no benefits from
entering native code in a GC unsafe mode. In fact we used to switch to GC
Safe mode for every statement in xamarin_release_managed_ref, and now we can
execute everything in GC Safe mode without switching back and forth. This
also means there should be no difference in behavior.
* All parameters are blittable, so there's no extra marshalling cost.
* Easier for CoreCLR.
* Avoids a native->managed transition
* Avoids creating/destroying a GCHandle.
* Makes it possible to remove an argument from the call to
xamarin_release_managed_ref.
* Makes things easier for CoreCLR.
* [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.
* [runtime] Port the is_user_type function from native to managed code.
* This is a straight forward port of native code to managed code, and
shouldn't have any significant side effects.
* Makes it possible to move more code from native to managed for
xamarin_create_managed_ref and xamarin_release_managed_ref in the future.
* Update xtro.
Make variables can have dashes, which means we don't have to convert dashes in
rids to underscores to be able to compose variable names.
This speeds up make because now we don't have to execute hundreds of
subprocesses when parsing the makefile.
Before:
$ make -j16 > /dev/null && /usr/bin/time make && /usr/bin/time make && /usr/bin/time make
2.11 real 0.57 user 1.26 sys
2.15 real 0.57 user 1.28 sys
2.17 real 0.58 user 1.30 sys
After:
$ make -j16 > /dev/null && /usr/bin/time make && /usr/bin/time make && /usr/bin/time make
0.52 real 0.18 user 0.25 sys
0.52 real 0.18 user 0.25 sys
0.52 real 0.18 user 0.26 sys
So now it's ~4x faster (1.6s) for make to figure out there's nothing to do.
I don't see why we should avoid calling xamarin_create_managed_ref from
NSObject's managed code, and then immediately call xamarin_create_managed_ref
upon return from NSObject's managed code.
This code is old ([1]), and from my reading of it, there's no specific reason
it was done this way.
Simplify the logic to call xamarin_create_managed_ref from a single place
(NSObject's managed code).
[1]: e59c45d3f9
Rolf Bjarne Kvinge
Manuel de la Pena
Sebastien Pouliot
dotnet-maestro[bot]
Peter Collins
mathieubourgeois