* [tests] Remove Classic SDK tests.
* Remove XI/Classic support.
This also means we can remove support for the legacy registrars.
* [monotouch-test] Remove legacy registrar tests.
* [tests/mtouch] Remove Classic tests (and legacy registrar logic).
* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
We've used the dynamic registrar for years now when selecting the IL registrar
(and I've never heard about anybody doing it), so just remove all the related
(and in fact dead) code.
* [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.
The watchOS device has limited networking support; in particular
it does not allow inbound/output network connections using 'bind'
(kernel-level sandbox restrictions).
This means that we can't use BSD sockets to connect to the debugger
in the IDE on the desktop. Instead we create an http tunnel that
knows how to convert socket send/recv data into http requests on
both sides.
https://bugzilla.xamarin.com/show_bug.cgi?id=41554
Launching a watchOS extension on device with the managed debugger
attached is slow, which means that the launch watchdog will kick in
and kill the app before it has launched.
So we attach the native debugger as well, which prevents the launch
watchdog from killing the app. Incidentally it also makes watchOS
not background the app.
We're using private API to determine whether a native debugger is
attached, but it's only in debug code, and as such would not be
included in release builds for customer apps. Also the code is
currently limited to watchOS since it's not needed on other
platforms for now.
The watchOS device has limited networking support; in particular
it does not allow inbound/output network connections using 'bind'
(kernel-level sandbox restrictions).
This means that we can't use BSD sockets to connect to the debugger
in the IDE on the desktop. Instead we create an http tunnel that
knows how to convert socket send/recv data into http requests on
both sides.
https://bugzilla.xamarin.com/show_bug.cgi?id=41554
Launching a watchOS extension on device with the managed debugger
attached is slow, which means that the launch watchdog will kick in
and kill the app before it has launched.
So we attach the native debugger as well, which prevents the launch
watchdog from killing the app. Incidentally it also makes watchOS
not background the app.
We're using private API to determine whether a native debugger is
attached, but it's only in debug code, and as such would not be
included in release builds for customer apps. Also the code is
currently limited to watchOS since it's not needed on other
platforms for now.
64-bit iOS 9+ devices have a pagesize of 16kb (even when running 32-bit apps).
This means all executable code must have sectors aligned to 16kb when running
on such devices.
The native linker uses the min iOS version to determine the sector alignment;
if min iOS version is < 8.0, then the sector alignment is 4k, otherwise 16k.
This means that when we create our 32-bit dylibs we must link them with a min
iOS version of 8.0, or they won't work on a 64-bit device in a 32-bit app (bug
So change our makefiles to link armv7[s] dylibs with min iOS version 8.0.
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=43102
Runtime
- Added support for Vector2d, Vector3d and Vector4d SIMD types
- Added support for GKBox, GKQuad and GKTriangle SIMD types
GameplayKit
- Apple introduced GKQuadTreeNode and GKQuadTree in Xcode 7.1 and
removed those types in a later Xcode (7.2?) but we kept them around.
Now apple introduced again both types but renamed them to GKQuadtreeNode
and GKQuadtree (lowercase t), this is a breaking change and since we do
care about binary compat we are just changing the registration name and
keeping the same managed name deprecating old methods and introducing
the new ones.
- Added tests for new SIMD types
In bug #43592 the following occurs:
* App calls an API that takes a block.
* We create a stack-based ObjC block based on the delegate the app provided.
This block has a pointer to a block description, describing the block
in question (including the signature of the block, as an ObjC-type
encoded string). We allocate a new block description for every block.
* Apple's API stores the pointer to the signature string somewhere.
* Apple calls _Block_copy to get a heap-based block.
* We create a heap-based block, and copy the entire description into the
new heap-based block (including a copy of the signature).
* Apple returns from the API, and then we free the stack-based block
(and the descriptor, and thus the signature string in the descriptor).
* Apple uses the pointer to the signature stored previously to investigate
the signature of the block, and crashes because this signature has been
freed.
The assumption in Apple's code is that the description will never be freed,
which is true for any Xcode project (clang will always be able to create the
block description at compile-time and emit it in the binary, which means the
memory will never be freed). We could potentially do the same thing in the
static registrar, but we'd still need a solution when using the dynamic
registrar.
To fix this instead of copying the entire description structure when creating
a heap-based block from the stack-based block, we make the description ref-
counted, and just use the same description in the heap-based block.
The signature will now stay in memory until both the heap-based and stack-
based blocks have been freed, and we hope Apple doesn't have any API that
needs the signature after all the blocks for that signature have been freed.
https://bugzilla.xamarin.com/show_bug.cgi?id=43592
* [spritekit] Update for iOS 10 beta 1
* [spritekit] Add missing MarshalDirective
* [runtime] Add missing simd function signatures
- Add matrix_float2x2 and matrix_float3x3 natives types.
* [introspection] Fix ApiSignatureTest
- We now avoid checking {?=[X]} encoded signatures.
- We now calculate the right size for matrix_float2x2, matrix_float3x3 and matrix_float4x4.
- Fix SKWarpGeometryGrid wrong bindings revealed by tests (IntPtr instead of Vector2).
* [monotouch-test] Add SKUniform and SKWarpGeometryGrid tests
The [NSURL URLByAppendingPathComponent:] will try and check if a file:///
url is point to a directory or not, and in that process it will read metadata
about the file, which strangely enough makes macOS create a new thread.
Just after calling URLByAppendingPathComponent: we will call setenv to set
MONO_REGISTRY_PATH to the calculated path.
At the same time (sometimes _exactly_ at the same time) the new thread will
read the current environment variables.
Since getenv/setenv isn't thread-safe (!!!), there's a race condition here
that may once in a while cause a crash (bug #37794).
So instead of calling URLByAppendingPathComponent: we call
URLByAppendingPathComponent:isDirectory:, thus telling the API
if the resulting path is a directory or not, which means it doesn't
have to check (and won't create any new threads).
So with this change Xamarin.Mac apps are effectively single-threaded
until we're done setting environment variables.
https://bugzilla.xamarin.com/show_bug.cgi?id=37794
The base directory and config file name is normally set automatically
when we ask Mono to execute the Main function, but in the case of extensions,
there is no Main function, so these values are not set, causing some
features (reflection-only assembly load) to not work correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=42784
The base directory and config file name is normally set automatically
when we ask Mono to execute the Main function, but in the case of extensions,
there is no Main function, so these values are not set, causing some
features (reflection-only assembly load) to not work correctly.
https://bugzilla.xamarin.com/show_bug.cgi?id=42784
* [XM] Dynamically look up NSExtensionMain to unbreak pre-10.10 XM apps
- So having a simple reference to NSExtensionMain is enough for /usr/lib/libextension.dylib to get added as a reference to libxammac.dylib
- If you have a reference to /usr/lib/libextension.dylib then any XM app (including our tests) bomb out on startup. This is suboptimal.
- So dlopen/dysm our way to victory.
* Fix spacing
Support binding NSObjects as IntPtr. This is usually not
a problem, because when we fetch the ObjC signature for a
method, we usually get the signature as exported by us,
(in which case a parameter bound as 'IntPtr' would be treated
as 'void *' in the dynamic registrar) *except* when the
selector corresponds with a protocol the type implements,
in which case we get the signature as defined in the protocol.
https://bugzilla.xamarin.com/show_bug.cgi?id=41132
* Restore the mono_jit_thread_attach signature to how it's in
the latest stable.
* Don't use the new attach/detach methods when using the dynamic
mono runtime, since the methods aren't available in any released
version of mono. Also XM doesn't support coop yet, so it's not
needed.
* And finally don't use the new attach/detach methods for anything
that isn't building using mono/master (iow only watchOS). This
should be changed once the rest of the products starts using
mono/master again.
This way we can pass pointers to managed objects to the native objects
without the coop GC interfering (since icalls won't automatically
switch to "gc safe" mode).
Usually mono does this for other apps, but not for watchOS (where mono doesn't
use signals at all).
watchOS can still raise signals though, so we need to ignore at least SIGPIPE.
The `_stret` API are not included in the ARM64 version of iOS (not
needed) but the removal of `dlsym` cause build failures*
So we're providing dummy symbols, just like what we did for tvOS,
to please the native linker (so nothing is undefined) and keep the
benefits of not using dlsym.
* Xamarin.iOS.dll (or other bindings) when the linker is disabled.
Normally the linker would remove the 32bits parts of the bindings
on a 64bits slice (and that would not be noticed). However we can
not assume this will be done for all binding projects, hence this
workaround.
We store $ebx at $ebp-12:
pushl %ebx # %ebp-12
so then storing xmm0 at $ebp-24:
movaps %xmm0, -24(%ebp)
would write 16 bytes between $ebp-24 and $ebp-8, thus overwriting
the place where we stored $ebx.
So allocate a bit more stack space and store the xmm registers
further 16 bytes down.
In particular NSMethodSignature chokes on encodings like this:
[NSDecimalNumber initWithDecimal:] = "@36@0:8{?=b8b4b1b1b18[8S]}16"
with an exception:
NSInvalidArgumentException Reason: +[NSMethodSignature signatureWithObjCTypes:]: unsupported type encoding spec '{?}'
so implement our own code to calculate the frame size.
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Chris Hamons
Vincent Dondain
Zoltan Varga
Sebastien Pouliot