This makes it possible to simplify and remove a good chunk of related code.
Especially for CoreCLR this should be a minor perf improvement, because we'll do fewer transitions between managed and native code.
If we're creating a universal app, and here are satellite assemblies that are not
identical across all RuntimeIdentifiers, those assemblies will be stored in a RuntimeIdentifier-specific
subdirectory during the build.
Unfortunately we didn't know how to find those assemblies at runtime, causing localizations
in universal apps to not work.
This change will:
* Add support for looking in the directory where RID-specific satellite assemblies
are stored.
* Add an assembly resolution event handler to our CoreCLR bridge so that we can
execute our custom lookup code.
* Add an assembly resource lookup test to monotouch-test.
* Add a macOS + Mac Catalyst variation of monotouch-test to xharness that triggers
the bug (a universal test app).
Fixes https://github.com/xamarin/xamarin-macios/issues/16847.
Use function pointers to our managed callbacks instead of delegates for the native->managed bridge. This makes execution faster on AOT (because the AOT compiler can just emit the native function address, no need to go through the expensive marshalling machinery).
This involved a few changes to make the managed callbacks only use blittable types in the function signature:
* Use `sbyte` / `int8_t` instead of `bool`.
* Use pointers instead of `out`/`ref` arguments.
* Use `IntPtr` instead of `string` arguments.
The code rarely shows up in timing profiles before the change, and never after. This means that time-wise this doesn't save all that much, because there wasn't much to gain to begin with (but it's still a gain).
Memory-wise, we're now allocation 0,19 MiB less on startup (17,61 MiB vs 17,42 MiB).
MonoVM in .NET 6+ supports automatic autorelease pools on threadpool threads
just like CoreCLR does, so we can remove our custom mono profiler hooks to
accomplish this.
Fixes https://github.com/xamarin/xamarin-macios/issues/11788.
This will increase app size a little bit: the space for the MVID + 4 bytes for each
assembly, but we'll be able to validate and show a helpful error message if the generated
static registrar code does not match the assembly loaded at runtime.
It's also a step toward per-assembly static registration (ref: #12067).
This avoids one case where we we embed metadata tokens to a different assembly
in the generated static registrar code.
This is required for supporting per-assembly static registration
(https://github.com/xamarin/xamarin-macios/issues/12067).
Wrap the call to UIApplicationMain in a @try/@catch handler, and convert any
Objective-C exceptions to a managed exception.
This way the managed Main method (which calls UIApplication.Main) will be able
to catch any Objective-C exceptions.
It's fairly frequent (due to various types of coding errors) to have the
call to '[self release]' in xamarin_release_managed_ref crash. These
crashes are typically very hard to diagnose, because it can be hard to
figure out which object caused the crash. So now we store the native
object in a static variable, so that it can be read using lldb from a core
dump.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1481312.
Allow code like this
```csharp
[DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSendSuper")
static extern IntPtr IntPtr_objc_msgSendSuper(IntPtr receiver, IntPtr selector);
[DllImport(Constants.ObjectiveCLibrary, EntryPoint = "objc_msgSendSuper")]
static extern void void_objc_msgSendSuper(IntPtr receiver, IntPtr selector, IntPtr arg);
[Export("selectedTextRange")]
public new IntPtr SelectedTextRange
{
get { return IntPtr_objc_msgSendSuper(SuperHandle, Selector.GetHandle("selectedTextRange")); }
set => void_objc_msgSendSuper(SuperHandle, Selector.GetHandle("setSelectedTextRange:"), value);
}
```
to work on the dynamic registrar since it already work with the static one.
This allows the simulators (which defaults to dynamic) to share the same code which is useful for implementing a workaround for related issue #15677.
There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused.
The bug is fixed in the Mono runtime (https://github.com/dotnet/runtime/pull/71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want.
This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds.
While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (https://github.com/xamarin/xamarin-macios/pull/15507). This means that the workaround is for .NET scenarios only.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
In the following scenario:
* Objective-C exception mode is to throw a managed exception.
* The xamarin_process_nsexception_using_mode was given a pointer to store any
resulting exceptions.
* The Objective-C exception didn't already have an associated managed exception.
We'd throw the managed exception upon return to managed code instead of
returning the managed exception.
With this change the xamarin_process_nsexception_using_mode will always return
the resulting managed exception in the scenario above (this way the behavior
is identical independent of whether the Objective-C exception already has an
associated managed exception or not).
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Handle managed exceptions a bit better when we know there won't be any other
managed frames further up the stack (such as in the main method). In this
case, there's no use in trying to convert the managed exception into an
Objective-C exception, because we already know the process will be terminated.
Instead just print the exception to stderr, and abort immediately.
This means we'll actually get some useful information printed to stderr.
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
If we try to process any exceptions, we'll throw an Objective-C exception,
which will likely be unhandled because we're pretty much at the top of the
stack, and when we handle this Objective-C exception we'll try to convert it
into a managed exception and throw that, and since there are no managed frames
on the stack we'll end up converting it to an Objective-C exception, which
we'll try to throw, and so on, eventually running into a stack overflow.
This is unnecessary, so just abort directly.
* We now create a tracking GCHandle for all NSObjects, not only the toggled ones.
CoreCLR will notify us when a tracked GCHandle's target enters finalization, and
we need to be notified for all NSObjects, not just the toggled ones.
* Augment the tracking callback to know about non-toggled objects, and in that
case report that the tracking GCHandle is a weak GCHandle.
* There's no need to store the tracking GCHandle in a field in the NSObject instance,
since we store it in our runtime object_map.
* Remove one place where we set the InFinalizerQueue flag, since it's no longer
required there (this reverts a previous attempt at fixing this problem - 0622ae4af2)
- we only set the InFinalizerQueue flag in the xamarin_coreclr_reference_tracking_tracked_object_entered_finalization
callback now.
* Update a few comments accordingly.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/13531.
Fixes https://github.com/xamarin/xamarin-macios/issues/13921 (again).
We were trying to call the 'retain' and 'autorelease' selectors on objects
that weren't NSObjects when returning them from function calls. For some
unfathomable reason that has worked until now, but I started running into this
problem with other (unrelated) changes, so it needs to be fixed.
The fix is to not call the 'retain' and 'autorelease' selectors on
NativeObjects, instead call into managed code to either call the Retain method
on the managed NativeObject (if we're supposed to retain the return value), or
if we have to autorelease the return value, then check first if the input is
an NSObject, and only then call retain+autorelease.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
This fixes an issue where the build would continue if the server in question
serves an error page (and eventually fail with weird errors because the error
page wouldn't be valid C code).
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
* Propagate the IsAppExtension variable correctly.
* Don't try to call mono_domain_set_config for app extensions in .NET.
It doesn't look like it's needed, and it also immediately aborts anyway, so
if it turns out to be needed, another solution would have to be implemented.
Fixes https://github.com/xamarin/xamarin-macios/issues/13742.
fixes#13160
- remove unused types
- use System.Numerics when possible
- move own created types from OpenTK namespace to CoreGraphics
- create missing types in CoreGraphics namespace
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When exception marshalling was originally implemented, for backwards
compatibility concerns it was only turned on by default for platforms that
really needed it (watchOS).
However, exception marshalling is by far the safest option, so in .NET we're
enabling it by default for all platforms (it's still possible to disable it
for those who wants to).
Ref: https://docs.microsoft.com/en-us/xamarin/ios/platform/exception-marshaling
* Make Runtime.Arch a readonly field.
* Tell the AOT compiler Runtime.Arch is a constant value.
* Tell the linker to stub out the method we use to fetch the current
architecture from native code (it turned out a bit complicated to set the
Arch field when it's readonly - the solution I came up with was to call a
P/Invoke).
Test case (size of the main executable): link all (debug)
* Before: 33.522.704 bytes
* After: 33.506.112 bytes
* Difference: -16.592 bytes (-0.05 %)
There were no size differences in release mode, nor were there any size
differences in the "don't link" test, neither for debug nor release mode.
Fixes https://github.com/xamarin/xamarin-macios/issues/5518.
This makes diagnosing what happens much easier in some cases.
Exhibit A, pre fix:
*** Terminating app due to uncaught exception 'ObjCRuntime.RuntimeException', reason: 'Failed to lookup the required marshalling information.
Additional information:
Selector: conformsToProtocol:
Type: ViewController
Exhibit B, post fix:
*** Terminating app due to uncaught exception 'ObjCRuntime.RuntimeException', reason: 'Failed to lookup the required marshalling information.
Additional information:
Selector: conformsToProtocol:
Type: ViewController
(ObjCRuntime.RuntimeException)
Failed to get the 'this' instance in a method call to templ.ViewController.InvokeConformsToProtocol. (ObjCRuntime.RuntimeException)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.GetMethodAndObjectForSelector(IntPtr klass, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.get_method_and_object_for_selector(IntPtr cls, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc, IntPtr& exception_gchandle)
Failed to marshal the Objective-C object 0x7f813fd2f470 (type: ViewController). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'templ.ViewController' does not have a constructor that takes one NativeHandle argument). (ObjCRuntime.RuntimeException)
at ObjCRuntime.Runtime.MissingCtor(IntPtr ptr, IntPtr klass, Type type, MissingCtorResolution resolution)
at ObjCRuntime.Runtime.ConstructNSObject[T](IntPtr ptr, Type type, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr ptr, IntPtr klass, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.GetNSObject(IntPtr ptr, MissingCtorResolution missingCtorResolution, Boolean evenInFinalizerQueue)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
It does exactly what you'd think it does: nothing helpful at all.
Make sure to use a GCHandle that's alive instead.
Output before fix:
Xamarin.Mac: Processing managed exception for exception marshalling (mode: 2):
Failed to print exception: System.NullReferenceException: Object reference not set to an instance of an object.
at ObjCRuntime.Runtime.PrintException(Exception exc, Boolean isInnerException, StringBuilder sb)
at ObjCRuntime.Runtime.PrintAllExceptions(IntPtr exception_gchandle)
Output after fix:
Xamarin.Mac: Processing managed exception for exception marshalling (mode: 2):
Failed to lookup the required marshalling information.
Additional information:
Selector: conformsToProtocol:
Type: ViewController
(ObjCRuntime.RuntimeException)
Failed to get the 'this' instance in a method call to templ.ViewController.InvokeConformsToProtocol. (ObjCRuntime.RuntimeException)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.GetMethodAndObjectForSelector(IntPtr klass, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
at ObjCRuntime.Runtime.get_method_and_object_for_selector(IntPtr cls, IntPtr sel, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc, IntPtr& exception_gchandle)
Failed to marshal the Objective-C object 0x7f89e6c2a2a0 (type: ViewController). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'templ.ViewController' does not have a constructor that takes one NativeHandle argument). (ObjCRuntime.RuntimeException)
at ObjCRuntime.Runtime.MissingCtor(IntPtr ptr, IntPtr klass, Type type, MissingCtorResolution resolution)
at ObjCRuntime.Runtime.ConstructNSObject[T](IntPtr ptr, Type type, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr ptr, IntPtr klass, MissingCtorResolution missingCtorResolution)
at ObjCRuntime.Runtime.GetNSObject(IntPtr ptr, MissingCtorResolution missingCtorResolution, Boolean evenInFinalizerQueue)
at Registrar.DynamicRegistrar.GetMethodDescriptionAndObject(Type type, IntPtr selector, Boolean is_static, IntPtr obj, IntPtr& mthis, IntPtr desc)
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Rolf Bjarne Kvinge
Sebastien Pouliot
Thays Grazia
Eric Sink
Alex Soto
Stephane Delcroix