* [runtime] Give a better error message if we can't load ObjCRuntime.Runtime.Initialize ()
Otherwise we'll get a SIGSEGV due to dereferencing NULL.
* Rework strings a bit to have fewer unique strings.
This avoids the use of `strcpy`, `memcpy` and `strlen` which can be
misused. We're already using ObjC code inside the file so we can
leverage higher-level API that makes review the code easier.
* [mmp] Set 'disable_omit_fp' by default to provide better native stack traces in certain cases.
This may produce better stack traces when crashes occur, which could be
helpful for tracking down issues like
https://github.com/xamarin/maccore/issues/643.
Also add an mmp option to override the default behavior.
This is unlikely to cause any problems, because Visual Studio for Mac sets
MONO_DEBUG=disable_omit_fp at launch, which means that all processes launched
by VSMac will also have this variable set already.
* Fix lldb attach disabling.
Help static analyzer by clarifying that only `char` will be given to
`isblank` so it does not look like it could be used to index an array
and gets out of bounds (important since this is user supplied values).
Digging down into `isblank` will get you to
> Using tainted variable _c as an index to array _DefaultRuneLocale.__runetype.
Change `redirect_io` to be easier to re-use correctly, i.e. returning the
file descriptor (instead of `0`).
Comment why the file descriptor are never released. It makes sense but
it's not obvious (even less in `redirect_io`) without comments.
Using static fields also makes it easier for static analysis (locals are
easier to process).
Finally reuse, mostly, the same string for the error message, i.e.
```
$ strings runtime//.libs/mac/libxammac.x86_64.dylib | grep "Could not redirect"
Xamarin.Mac: Could not redirect %s to `%s': %s
```
versus
```
$ strings runtime//.libs/mac/libxammac.x86_64.dylib | grep "Could not redirect"
Xamarin.Mac: Could not redirect stdout to `%s': %s
Xamarin.Mac: Could not redirect stderr to `%s': %s
```
`get_mono_env_options` allocate memory so it must [1] be freed.
[1] to be polite since it will be freed when the app exit, which
will free everything anyway
* [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.
* Store the minimum mono version for Xamarin.Mac in one place only (Make.config) and bump it to 5.14. Fixes#4120.
I've verified that we fail at launch of running on 5.12, while 5.14 works fine
(to launch at least), so the minimum system mono version is _at least_ 5.14.
Fixes https://github.com/xamarin/xamarin-macios/issues/4120.
* [mmp] Load mono's version file instead of using pkg-config to get mono's version.
pkg-config will only get three parts of the version, while the version file
has all four parts.
This is important, since we're now verifying the four parts of the version
file, and without loading those four from the system, we'll fail builds like
this:
error MM0001: This version of Xamarin.Mac requires Mono 5.14.0.136 (the current Mono version is 5.14.0).
because the three part version's fourth number is assumed to be 0.
* Only verify mono runtime version when running with system/dynamic mono.
There should be no need to verify the mono runtime version when embedding mono:
* If it's a mono we're shipping, something very bad happened in our
build/package for it to be an invalid mono.
* If it's a system mono that's being embedded, then we verify in mmp at build
time.
In the first scenario (a mono we're shipping), the problem is that the mono
we've built does not report back the full version number (with four parts) [1],
which means we'll fail any check whose requirements are identical for the
first three parts, and non-zero for the last.
[1] The fourth part of the version number is created/calculated when packaging
mono, and we're not packaging it.
* [Launcher] Don't set the configuration dir to the bundle
When using system-mono launcher, do not make mono probe for
configuration files in the bundle, but rather rely on the
default behaviour of system mono resolving it to /etc/mono
* Update comments
* Update to mono 2017-04 branch
* Patch from Zoltan to fix build error with CppSharp.CppParser.dll
* Include new linker files in Makefile, based on mareks commit
* [msbuild] Fix running bgen for Xamarin.Mac.
bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.
* System.Data tests should act as if they are running on mobile profile
* Add --runtime=mobile to mono flags in Modern
* Move runtime launcher options up
* System.Data tests should use Mobile profile (mac fix)
* Bump 2017-04 to pick up AOT and assembly resolution fixes
* Build fixes for netstandard.dll and System.Drawing.Primitives.dll
The new handling went in with https://github.com/mono/mono/pull/4501.
I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.
* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS
* Fix 2.1/Facades/netstandard.dll build
* Fix the netstandard targets
* Bump mono to latest 2017-04 commit
* [xharness] Fix adding defines to csproj by correctly detecting existing defines.
* Bump mono to latest 2017-04 commit
* [mtouch] Update csproj with new files.
* [mtouch] Improve reporting for MarkExceptions from the linker.
* Bump mono to latest 2017-04 commit
* Bump mono to pick up latest 2017-04 branch commit (Fixes#55436)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436
* Add a missing Makefile dependency
* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time
(It is currently being applied for some configurations at runtime only)
* Bump system mono
* Bump mono for assembly loader changes
* Bump system mono
* Update assemblies list as some where moved to facades
6ca5ec442bc38e4d9220
* Bump mono to latest 2017-04 commit
* Add another new facade
* Bump mono to tip of 2017-04.
* Bump mono to tip of 2017-04.
* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes#56307 and #56308.
System.dll is now completely linked away unless the app actually uses any
System.dll API.
This is the change that caused this to change: 4960d5d2a2
Previously the following types would always be kept by the linker:
```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```
Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).
With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.
I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.
This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.
This means that the fix is to modify these tests accordingly.
https://bugzilla.xamarin.com/show_bug.cgi?id=56307https://bugzilla.xamarin.com/show_bug.cgi?id=56308
* Bump mono to latest.
* Fix merge conflict that was missed
* [mtouch] Renumber new error which clashes with an existing error number in master.
- Actually enable hybrid AOT by adding argument in right location
- Hybrid AOT and stripping does not play well currently with partial AOT
- Fix AOT makefile to work with nuget nunit
- https://bugzilla.xamarin.com/show_bug.cgi?id=55041
I've spent way too much time looking at the console waiting for things to
appear, all the while a dialog has hid away beneath other windows on my
system, waiting indefinitely for my attention.
* [runtime] Fix broken indentation to make code less confusing.
* [runtime] Rework initialization for Xamarin.Mac extensions.
1. Delay the Application.Init execution from step 6 in the initialization
sequence, to when we'd run the managed Main function for a normal app. This
makes the code a bit easier to reason about, since both code paths behave
more similar. It's also matches the initialization documentation better
(step 6 is "find the executable", not "find the executable and run
Application.Init").
2. Install custom callbacks for mono's logging function just before calling
Application.Init. We already install these custom callbacks in
xamarin_initialize, but that doesn't help much if something goes wrong
before xamarin_initialize is called (and there's no harm in doing this
twice).
3. Treat the extension dll as an entry assembly, make the path to the entry
assembly available to managed code, and load this assembly if
Assembly.GetEntryAssembly can't find it (which happens for extensions,
since there's no entry point as Assembly.GetEntryAssembly defines an entry
assembly).
This fixes launching of Xamarin.Mac extensions.
* [runtime] Spaces -> tabs.
Store the launch mode in a static variable instead of storing if we're an
extension (since the launch mode also contains that information).
Also pass the launch mode around in Xamarin.Mac's initialization data.
* Bump maccore to get fix for launching the simulator for app extensions.
* [runtime] Don't look in shared memory for debug data in normal apps.
Don't look in shared memory for debug data in normal apps, because it
interferes when debugging extensions from the same solution as a container
app:
Example, for a keyboard extension:
1. Run extension in XS.
2. Manually launch the extension's container app (which contains a textbox
that can be used to launch the keyboard).
3. The container app reads the debug data in shared memory which was intented
for the extension, and takes over the debugger.
4. Launch keyboard, which will not be able to connect to the IDE because the
container app already connected to the IDE.
* [XM] Seperate parsing from compilation in AOT code
- Parsing command line options was too entangled with actually compiling
- Refactor test code to centralize Compile, reducing some complexity of tests
- Groundwork for hybrid vs non-hybrid AOT work
* Add hybrid/standard AOT support
* Add xammac_tests to makefile/jenkins
* Add flag to force AOT
* Disable MonoTouchFixtures.Contacts.ContactStoreTest.GetUnifiedContacts on XM due to prompts on Jenkins
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
* [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