* [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
Any performance difference will be neglible compared to running the GC, so
there's no compelling reason to use the embedding API.
This makes things a bit easier with CoreCLR, since the new code works there too.
This also required a few changes in delegates.t4 to make code generation for
functions without arguments work correctly.
* Avoids one usage of xamarin_set_nsobject_flags (which pokes into managed
memory from native code, which won't be possible with CoreCLR).
* Makes it possible to move more code from native to managed for
xamarin_release_managed_ref in the future.
* Since the code order is exactly the same, it shouldn't have any other side
effects.
* Add configure option to disable building for legacy Xamarin.
This can greatly speed up the debug-edit-build cycle when doing .NET
development, since it cuts down the build time in half more or less.
* Bump maccore.
New commits in xamarin/maccore:
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Diff: 0562e08b12..548fa45432
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
This makes it so that it's possible to attach to the debugger by setting the
__XAMARIN_DEBUG_HOSTS__/__XAMARIN_DEBUG_PORT__ environment variables, without
the need for enabling a setting somewhere else (like in
Settings.bundle/Root.plist on mobile devices).
This also means linking with the runtime packs from .NET instead of the mono archive
(thus we have one less reliance on the mono archive).
We're also using the Xamarin.iOS code for our macOS launch sequence now, since
(at least at first) we're only going to support self-contained .NET macOS apps
(so no need to support a system-installed runtime, which simplifies things a
bit).
* Convert the GCHandles interface from 32-bit ints to pointer size types
This involves:
* Stop using some bits of the GCHandle to store extra flags, instead add an extra
field to store those flags.
* Define a INVALID_GCHANDLE constant and use it instead of 0/NULL. This is not
strictly required, but it makes the code more self-documenting.
* Define a GCHandle type (typedef'ed to void*) and change all variables and parameters
to use it instead of guint32.
* Use our own xamarin_gchandle_* methods (with pointer-sized types) that wraps
the mono_gchandle_* embedding API (which uses 32-bit types) everywhere.
* Update managed code (registrars, runtime code, etc) accordingly.
* [runtime] Make debug code compile.
* Fix typo.
* Fix signature of xamarin_create_gchandle.
Co-authored-by: Aaron R Robinson <arobins@microsoft.com>
Sebastien Pouliot
Peter Collins
Rolf Bjarne Kvinge
mathieubourgeois