Граф коммитов

40 Коммитов

Автор SHA1 Сообщение Дата
Rolf Bjarne Kvinge 34f58bbed4
[runtime] Use calloc instead of malloc. (#20692)
It's safer, since the returned memory is zero-initialized.

Also add tests.
2024-06-07 16:56:54 +02:00
Rolf Bjarne Kvinge 21705ee361
[runtime] Use objc_[retain|release|autorelease] instead of sending messages. (#19415)
Calling the direct functions instead of sending messages is slightly faster,
and additionally it may make some static analyzers think we've enabled ARC for
our Objective-C code (which we don't, because we need to manually manage
reference counting).

These direct functions aren't in any public header (they're in a private header),
but they're documented as part of ARC here: https://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support,
and clang emits references to these methods from user code, so it should be safe for us to use them.

Fixes https://github.com/xamarin/xamarin-macios/issues/19413.
2023-11-14 07:42:55 +01:00
Rolf Bjarne Kvinge a82575189b [CoreCLR] Add support for mono_assembly_open.
This includes going through all uses of mono_assembly_open, and make sure the release
the returned assembly.
2021-03-25 07:32:32 +01:00
Rolf Bjarne Kvinge 363f4611db
Use our [OBJC_]CFLAGS when compiling code for macOS. (#10771)
This required fixing a couple of compiler warnings in code that's now compiled
with more warnings + warnings-as-errors enabled:

    launcher.m:188:48: error: implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion]
            argv = (char **) malloc (sizeof (char *) * (n + 1));
                                                     ~  ~~^~~
    launcher.m:609:67: error: implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion]
                    char **new_argv = (char **) malloc (sizeof (char *) * (new_argc + 1 /* null terminated */));
                                                                        ~  ~~~~~~~~~^~~
2021-03-03 21:41:39 +01:00
Rolf Bjarne Kvinge adb566e408
[runtime] Simplify code for custom mono bundle name a bit by using a default value for the 'xamarin_custom_bundle_name' variable. (#10130) 2020-11-23 08:30:08 +01:00
Filip Navara d602cf76cf
[dotnet] Fix install name for libxamarin[-debug].dylib on macOS (#9821)
* [dotnet] Fix install name for libxamarin[-debug].dylib on macOS

* When using DYNAMIC_MONO_RUNTIME pass down the bundle directory in MONO_PATH to the relaunched process. Also fix support for custom bundle names in the surrounding code.

* Fix pattern matching
2020-10-09 14:55:00 +02:00
Filip Navara 59db084141
Respect xamarin_executable_name on macOS if specified (#9803) 2020-10-08 18:23:39 +02:00
Rolf Bjarne Kvinge 5a85c17e6d
[runtime] Give a better error message if we can't load ObjCRuntime.Runtime.Initialize () (#9514)
* [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.
2020-08-27 13:29:12 +02:00
Sebastien Pouliot 4a23951829
[runtime] Fix warning in launcher.m (#8891)
```
launcher.m:136:9: warning: unused variable 'size' [-Wunused-variable]
        size_t size;
               ^
1 warning generated.
```

missed in https://github.com/xamarin/xamarin-macios/pull/8853
2020-06-19 09:40:01 -04:00
Sebastien Pouliot 44d3e1b7ba
[runtime] Simplify string code inside launcher by using ObjC (#8859)
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.
2020-06-17 10:03:35 -04:00
Sebastien Pouliot 0187a45359
[runtime] Have launcher use https-based URL if mono is missing (#8855) 2020-06-15 14:21:15 -04:00
Sebastien Pouliot 65901a6f29
[runtime] Update launcher to use `strndup` (#8853)
because now we can :)
2020-06-15 13:46:01 -04:00
Rolf Bjarne Kvinge 2b733ae79c
[mmp] Set 'disable_omit_fp' by default to provide better native stack traces in certain cases. (#7981)
* [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.
2020-02-26 15:49:55 +01:00
Sebastien Pouliot c46d9857a4
[runtime] Filter isblank input to 8 bits values (#7420)
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.
2019-11-13 20:46:20 +01:00
Sebastien Pouliot 0b323ca4cd
[runtime] Clarify redirect_io behaviour (#7409)
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
```
2019-11-12 12:34:49 +01:00
Sebastien Pouliot e55e434213
[runtime] Free `env-argv` in `xamarin-main` (#7352)
`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
2019-11-04 08:56:59 -05:00
Chris Hamons 155bb924de
Revert "[launcher] Pass --use-map-jit to mono on XM app startup" (#6051)
- This reverts commit 2278512aba.
- This is no longer necessary due to https://github.com/mono/mono/pull/14395
2019-05-16 15:09:02 -07:00
Chris Hamons 2278512aba [launcher] Pass --use-map-jit to mono on XM app startup
- Related: https://github.com/mono/mono/pull/13446
    - Patch by Miguel
2019-04-12 18:06:28 +02:00
Rolf Bjarne Kvinge 02fe5339a4
[runtime] Clean up public symbols. Fixes #5124. (#5155)
* [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.
2018-11-21 11:48:15 -05:00
Rolf Bjarne Kvinge 33c1db4b68
Store the minimum mono version for Xamarin.Mac in one place only (Make.config) and bump it to 5.14. Fixes #4120. (#4695)
* 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.
2018-08-29 14:28:56 +02:00
Eberhard Beilharz 78583313eb Fix download path for mono (#3681) 2018-03-07 14:46:59 +01:00
Rolf Bjarne Kvinge 4be1cd723b
[runtime] Enable signal chaining for Xamarin.Mac apps. (#3631)
Reported in the forums: https://forums.xamarin.com/discussion/122594/xamarin-mac-signal-handling
2018-03-02 09:42:16 +01:00
Marius Ungureanu 5d50f81cb8 [runtime] Use mono's runtime default to load config files when it's not embedded (#3290)
* [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
2018-01-29 16:58:33 +01:00
Andi McClure a6cf8c5edc [Do not merge yet] Update to mono 2017-04 branch (#1960)
* 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

6ca5ec442b
c38e4d9220

* 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=56307
https://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.
2017-05-29 18:39:29 +02:00
Chris Hamons 562560d936 Fixup Xamarin.Mac Hybrid AOT and improve testing (#1995)
- 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
2017-05-16 13:29:08 -05:00
Rolf Bjarne Kvinge f8885d00df [runtime] Print any dialogs messages to the console as well. (#2090)
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.
2017-05-15 20:12:34 -04:00
Rolf Bjarne Kvinge 5350fc3cd8 [runtime] Rework initialization for Xamarin.Mac extensions. (#2091)
* [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.
2017-05-11 17:44:58 +02:00
Rolf Bjarne Kvinge c3cecd577f [runtime] Fix XM extension launch mode. (#2086) 2017-05-11 10:28:56 +02:00
Rolf Bjarne Kvinge 98777d5774 [runtime] Teach our runtime about where things are when in embeddinator mode on macOS. 2017-05-09 08:12:39 +02:00
Rolf Bjarne Kvinge ad3a4a12eb [runtime] Store the launch mode in a static variable.
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.
2017-05-09 08:12:39 +02:00
Rolf Bjarne Kvinge 1afae37c7f [runtime] Add support for initializing in an embedder mode. 2017-04-18 11:13:42 +02:00
Rolf Bjarne Kvinge 24dacc6d02 [runtime] Don't look in shared memory for debug data in normal apps (#1841)
* 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.
2017-03-08 20:00:58 +01:00
Chris Hamons 2c835c5294 [XM] Add hybrid/standard AOT option and improve AOT code (#1650)
* [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
2017-02-08 13:40:48 -06:00
Chris Hamons ffe142d0b5 [XM] AOT support in Xamarin.Mac (#1340) 2017-01-11 14:10:39 -06:00
Chris Hamons 17bb354dca [XM] Fix 44707 by fixing launcher and mmp (#971)
- https://bugzilla.xamarin.com/show_bug.cgi?id=44707
- Sets MONO_CFG_DIR to work around embedding API bug: https://bugzilla.xamarin.com/show_bug.cgi?id=45279
- Added ability to run single XM test by setting XM_TEST_NAME to full test name.
2016-10-13 10:42:05 -05:00
Chris Hamons 1c6e1959b7 [XM] Add support for disabling lldb attach on crash (#670)
- https://bugzilla.xamarin.com/show_bug.cgi?id=23482
2016-08-25 13:06:38 -05:00
Rolf Bjarne Kvinge eed9b5d8d0 [runtime] Specify if MONO_REGISTRY_PATH points to a directory or not. Fixes #37794. (#514)
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
2016-08-01 16:14:21 +02:00
Chris Hamons b7a797b068 [XM] Dynamically look up NSExtensionMain to unbreak pre-10.10 XM apps (#154)
* [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
2016-06-09 00:19:16 +02:00
Chris Hamons ca028ea150 [Mac] Add support for os x extensions (#83) 2016-05-25 17:20:33 -04:00
Rolf Bjarne Kvinge ac418df815 Build our runtime. 2016-04-24 14:47:24 -04:00