This allows the optimization to be disabled in cases where one, or
many, a custom attribute(s) are required by the application at runtime.
While not ideal disabling this single step is much better than disabling
linking for the whole application.
A better approach is described in https://github.com/xamarin/xamarin-macios/issues/6048
but this configuration optimization makes sense independently of it.
Fix https://github.com/xamarin/xamarin-macios/issues/3655
The arm64_32 slice for watchOS apps will always use the 'unified' mode, while
the armv7k can be both 'unified' and 'compat' depending on the deployment
target, so we need to keep track of this per Target.
This PR does not change anything related to arm64_32, that will come in a
later PR.
Fixes this NRE:
error MT0000: Unexpected error - Please file a bug report at https://github.com/xamarin/xamarin-macios/issues/new
System.ArgumentNullException: Value cannot be null.
Parameter name: collection
at System.Collections.Generic.List`1[T].InsertRange (System.Int32 index, System.Collections.Generic.IEnumerable`1[T] collection) [0x00003] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at System.Collections.Generic.List`1[T].AddRange (System.Collections.Generic.IEnumerable`1[T] collection) [0x00000] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at Xamarin.Bundler.Application.BuildApp () [0x00040] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:1541
at Xamarin.Bundler.Application.BuildNative () [0x0001f] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:903
at Xamarin.Bundler.Application+<>c.<BuildAll>b__148_2 (Xamarin.Bundler.Application v) [0x00000] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:840
at System.Collections.Generic.List`1[T].ForEach (System.Action`1[T] action) [0x0001e] in <a104f9cbbafd4348bcc580acb0a3f8a8>:0
at Xamarin.Bundler.Application.BuildAll () [0x00076] in /work/maccore/master/xamarin-macios/tools/mtouch/Application.cs:840
at Xamarin.Bundler.Driver.Main2 (System.String[] args) [0x004a1] in /work/maccore/master/xamarin-macios/tools/mtouch/mtouch.cs:1369
at Xamarin.Bundler.Driver.Main (System.String[] args) [0x00015] in /work/maccore/master/xamarin-macios/tools/mtouch/mtouch.cs:877
According to Rolf it's fine to always add since the native linker will
figure out if it's really needed and so customers don't need to do
anything when using -all_load.
Mono started using System.IO.File from CoreFX and it has a different
behavior for File.Copy() when the target is a directory:
It just puts the file into the directory instead of raising an exception.
In order to fix the MT1015 test we just check ourselves whether the target
is a directory.
This also centralize other interpreter checks and options in the same
location (making it easier to read / update).
* Warn and switch the REPL if the interpreter is enabled on simulator
Why ? It's confusing to build the same code using different options for
simulator and devices. This is what happens if you try to use features
like `dynamic` or `System.Reflection.Emit`.
So instead of an error, we warn that the interpreter is not supported
and switch to the existing REPL mode.
The JIT remains the only option for the simulator but it allows testing
features without a device.
* Fail early if the interpreter is used on 32bits [1]
The current interpreter only works on 64 bits (so ARM64). However the
error won't be reported, back to the developer, until deployment time.
This temporary [1] fix spot the condition very early and report an error
```
error MT0099 : Internal error : The interpreter is currently only available for 64 bits.
```
instead of the current one at deploy time
```
IncorrectArchitecture: Failed to find matching arch for 32-bit Mach-O input file /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.tNKDlx/extracted/X.app/X
error MT1006: Could not install the application 'X.app' on the device 'Mercure': AMDeviceSecureInstallApplicationBundle returned: 0xe8000087 (kAMDIncorrectArchitectureError).
Application could not be uploaded to the device.
```
[1] https://github.com/mono/mono/issues/9871
* [tests] Fix/renumbered MT0138
The test was using simulator + interpreter which is not _really_
possible, we use REPL in that case - so we're now checking if
assemblies were specified with `--interpreter` to cover both cases.
Also 0138 was already used by `mmp` and the warning was **not**
registered or documented in the errors documents. To avoid
confusion it has been renumbered to 0142 and documented.
In both cases we use a different binaries for a few assemblies. They
include support for SRE and a few other things that are not normally
usable on iOS. That's totally fine and not something that can be fixed
(unless you stop using the feature). So this PR simply ignore that
specific case so we don't warn about things that can't be changed (and
are not a problem)
E.g.
```
Warning MT0109: The assembly 'mscorlib.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/mscorlib.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/mscorlib.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Core.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Core.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.dll). (MT0109) (XXX)
Warning MT0109: The assembly 'System.Xml.dll' was loaded from a different path than the provided path (provided path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll, actual path: /Users/poupou/git/intr/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/repl/System.Xml.dll). (MT0109) (XXX)
```
document it and adjust the optimization tests.
This allows the optimization to be:
* disabled (if ever needed) on fully AOT'ed applications
* re-enabled for the interpreter (at your own risk)
* We only need to do a runtime check on watchOS.
* On watchOS assume we're on a ARM64-based CPU as long as we're not on a
ARMv7k CPU.
Fixes an issue where we failed to detect a 64-bit iOS CPU as ARM64-based (in
particular iPhone X's ARM64v8).
The Mono AOT compiler maintains a set of signatures of compiled methods.
Those signatures are necessary to emit wrappers to enable the transition
from interpreter->AOT code. Thus, they must be collected for each
assembly.
Clang will automatically compile .bc files into object code if needed, but
it's done serially. If we do the compilation ourselves, it'll be parallelized.
This makes the dontlink tests build in half the time when building for watchOS
/ Release (it drops from ~15 minutes to ~7 minutes).
The AOT compiler uses the 'outfile' as the base for a temporary .bc file. If
it's not set, the path to the assembly is used as the base instead. This does
not work if we compile the same assembly to multiple architectures (for
instance armv7k+arm64_32), because the temporary file will clash between those
AOT compilations.
This is not a problem for iOS (armv7+armv7s) because we don't compile to
bitcode (.bc files) on iOS.
* [mtouch] Don't use the native linker to create fat executables.
Don't use the native linker to create fat executables, instead link each
architecture separately, and then manually lipo everything together at the
end. This requires a few changes since we need to keep track of the linker
flags per architecture.
The problem is that bitcode files (.bc) do not correspond with a particular
architecture, so the linker can't distinguish between .bc files for armv7k and
.bc files for arm64_32. So if we pass all together to the linker, the linker
will add all .bc files to both architectures, thus duplicating everything (and
the linking fails with duplicate symbols errors).
* [mtouch] Fix building symlinked simulator executables.
* [mtouch] Fix several assumptions about each Target only producing a single executable.
Also change output to use the full path to files as nodes, instead of just the
filename, and instead use a label to set what's shown to just the filename.
This makes the graph correct when we have multiple files with the same name,
but different paths.
We need our 32-bit and 64-bit assemblies to be identical so that we can avoid
duplicating the .dll in fat apps.
One difference used to be that the .dll contained the full path to the
corresponding .pdb ([1]), but we changed cecil to only write the filename
([2]). Unfortunately this change breaks something else, so it has to be
reverted ([3]).
This implements a different solution: we provide a custom symbol writer to
Cecil, which only writes the filename of the pdb in the .dll, not the full
path.
[1]: https://bugzilla.xamarin.com/show_bug.cgi?id=54578
[2]: https://github.com/jbevain/cecil/issues/372
[3]: https://github.com/jbevain/cecil/pull/554
(cherry picked from commit 53874c863996656eaba43a5582731b93eb6f53b7)
# Conflicts:
# tools/mtouch/mtouch.csproj
* Add a Runtime.IsARM64CallingConvention property.
Determining whether we should use the ARM64 calling convention in P/Invokes
gets more complicated with ARM64_32 (which for our purposes is a 32-bit
architecture).
So add a property on the Runtime class to avoid code duplication, and teach
the linker to optimize any calls to this property to a constant value whenever
possible (and the method is marked as optimizable).
Also change our code to use this new property, and make the corresponding
methods optimizable.
Some shuffling in mmp was required, which meant a little bit more code is now
shared between mtouch and mmp.
* Coding style.
* Test tweaks.
* Improve comment.
* Document new optimization
* Move ILReader to shared linker test code location.
* Disable inlining on armv7k.
* Change IsARM64CallingConvention to a read-only field.
We can give the AOT compiler a constant value for a read-only field, so that
the AOT compiler optimizes away the call to the field by using the constant
value.
This commit does not implement this change for the AOT compiler, but using a
read-only field makes it easy to implement it in the future.
* [linker] Remove non-bitcode compatible code, and show a warning.
Remove code not currently compatible with bitcode and replace it with an
exception instead (otherwise we'll assert at runtime).
Also show a warning when we detect this.
This is quite helpful when looking at watch device test runs to filter out
failures we already know about.
This fixes point #2 in #4763.
* Improve documentation.
* Simplify linker code by using a substep.
* Fix whitespace issues.
* Improve reporting.
* Add support for reporting more than one MT2105 at the same time when making
the errors instead of warnings.
* Only report MT2105 for methods that haven't been linked away.
* Format the error message nicer for properties.
* Tweak a bit for warning tests to pass.
* Use ExceptionalSubStep to provide better error information.
* Adjust where linker warnings/errors are reported from to avoid a NullReferenceException.
Bernhard Urban
monojenkins
Alexander Köplinger
Vlad Brezae
Rolf Bjarne Kvinge
Sebastien Pouliot
Bernhard Urban