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

36 Коммитов

Автор SHA1 Сообщение Дата
monojenkins d62978945d [d16-2] [linker] Add the custom attributes removal step as an configurable optimization. Fix #3655 (#6058)
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
2019-05-16 16:55:10 -05:00
Sebastien Pouliot a9f8d7b379
[mtouch][mmp] Add control over the the linker new `BeforeFieldInit` optimization (#5820)
Add an mtouch/mmp optimization flag to control this new optimization since
3rd party code (in particular binaries) might depend on this side effect.
2019-04-01 21:21:56 -05:00
Sebastien Pouliot ea96b2299a
[mtouch] Make the SealerSubStep a configurable optimization (#5766)
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)
2019-03-14 08:12:17 -05:00
Rolf Bjarne Kvinge 5571877312 [mtouch] Use a custom symbol writer to ensure only pdb file names are written to assemblies.
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
2019-02-13 14:59:34 +01:00
Rolf Bjarne Kvinge 135507957f
[linker] Remove non-bitcode compatible code, and show a warning. (#5551)
* [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.
2019-02-07 07:57:01 +01:00
Marek Safar 10d98e67d8 [mtouch] Pass features not available on iOS to linker (#4426) 2018-07-24 22:30:18 -04:00
Sebastien Pouliot b2e6aba41c
[mtouch][mmp] Add better easier, more complete timestamps to see where time is spent (#4150)
* Share the stopwatch code between `mtouch` and `mmp`;

* Add more details on linker steps. Sadly substeps are executed on the
  metadata so they can't be reported individually;

* Add a few places where timestamps where missing to get better precision
  on the linking part;
2018-05-29 13:08:34 -04:00
Rolf Bjarne Kvinge 9be59296ae
[linker] Rename the MonoTouchTypeMapStep class to CoreTypeMapStep since it's shared between XI and XM. (#3482) 2018-02-15 00:44:11 +01:00
Rolf Bjarne Kvinge af03020eef
[mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp. (#3242)
* [mtouch/mmp] Give users more control over optimizations, and share more code between mtouch and mmp.

1. Add an --optimize flag to mtouch/mmp that allows users to select which
   optimizations to apply (or not). This makes it easier to add future
   optimizations, and allow users to disable any optimization that causes
   problems without having to disable many other features.

2. Share as much optimization code as possible between mtouch and mmp. This
   immediately gives a benefit to mmp, which has three new optimizations only
   mtouch had: NSObject.IsDirectBinding inlining, IntPtr.Size inlining and
   dead code elimination.

   This results in ~6kb of disk space saved for a linked Xamarin.Mac app:

   * link sdk: [Debug][1], [Release][2]
   * link all: [Debug][3], [Release][4]

Testing also verifies that monotouchtest ([Debug][5], [Release][6]) has not
changed size at all, which means that no default optimizations have changed
inadvertedly.

[1]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--debug
[2]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-sdk-mac--release
[3]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--debug
[4]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#link-all-mac--release
[5]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonedebug64
[6]: https://gist.github.com/rolfbjarne/6b731e3b5ca6170355662e6505c3d492#monotouchtest-iphonerelease64

* [tools] Don't enable the IsDirectBinding optimization by default for Xamarin.Mac apps, it's not safe.

* Fix whitespace issues.

* [doc] Document optimizations.

* Officially support optimizations by adding them to the Versions.plist.

* [linker] Improve IntPtr.Size inliner + dead code eliminatior and add tests.

* Properly handle operands for the ldc_i4_s instruction (they're sbyte).
* Fix less-than condition to actually do a less-than comparison.
* Make sure to look up the bitness in the Target, not the Application, since
  the Application's value will be incorrect when building fat apps (both
  Is32Build and Is64Build will be true).
* Remove unnecessary checks for the IntPtr.Size inliner: this optimization
  does not depend on other instructions than the IntPtr.get_Size call, so
  remove the checks that verify surrounding instructions. This makes the
  IntPtr.Size inliner kick in in more scenarios (such as the new tests).
* Add tests.

* [tests] Add mmp tests for optimizations.

* [tests] Fix XM optimization tests.

* [tests] Fix test build error.
2018-01-23 11:33:48 +01:00
Rolf Bjarne Kvinge a979a10412 Merge remote-tracking branch 'origin/master' into bindas-registrar-support 2017-09-22 10:50:07 +02:00
Sebastien Pouliot 32ae1d4e63 [mtouch][mmp] Add better diagnose for bugs #59570 and #58063 (#2745)
Bug #59570 was a dupe of #58063 but was harder (than it should be) to
diagnose because the error did not point out which assembly had the
issue (requiring a whole, large, customer solution to confirm).

This adds a new MT2103 error which points to the assembly that could
not be read.

E.g. VSfM will now show

> Error MT2103: Error processing assembly 'Shim, Version=2.0.1.0, Culture=neutral, PublicKeyToken=c55ec16d10c4b366': System.NullReferenceException: Object reference not set to an instance of an object (MT2103) (...)

[1] https://bugzilla.xamarin.com/show_bug.cgi?id=59570
[2] https://bugzilla.xamarin.com/show_bug.cgi?id=58063
2017-09-21 20:22:12 -04:00
Rolf Bjarne Kvinge bdd4e48cfb [linker] Preserve smart enum conversion methods when needed. 2017-07-06 20:27:13 +02:00
Andy Martin 86b1fd2db5 fixes a null reference exception that can be caused during compile time related to bug 57214 (#2172) 2017-06-04 18:40:28 -04:00
Rolf Bjarne Kvinge d17cb6556a [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes #51710 and #54417. (#2162)
* [mtouch] Improve how we make sure native symbols aren't stripped away. Fixes #51710 and #54417.

* Refactor required symbol collection to store more information about each
  symbol (field, function, Objective-C class), and in general make the code
  more straight forward.
* Implement support for generating source code that references these symbols,
  and do this whenever we can't ask the native linker to keep these symbols
  (when using bitcode). Additionally make it possible to do this manually, so
  that the source code can be generated for non-bitcode platforms too (which
  is useful if the number of symbols is enormous, in which case we might
  surpass the maximum command-line length).
* Also make it possible to completely ignore native symbols, or ignore them on
  a per-symbol basis. This provides a fallback for users if we get something
  right and we try to preserve something that shouldn't be preserved (for
  instance if it doesn't exist), and the user ends up with unfixable linker
  errors.
* Don't collect Objective-C classes unless they're in an assembly with
  LinkWith attributes. We don't need to preserve Objective-C classes in any
  other circumstances.
* Implement everything for both Xamarin.iOS and Xamarin.Mac, and share the
  code between them.
* Remove previous workaround for bug #51710, since it's no longer needed.
* Add tests.

https://bugzilla.xamarin.com/show_bug.cgi?id=54417
https://bugzilla.xamarin.com/show_bug.cgi?id=51710

* [mtouch] Make sure to only keep symbols from the current app when code sharing.

This fixes a build problem with the interdependent-binding-projects test when
testing in Today Extension mode.
2017-06-02 18:29:19 +02: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
Rolf Bjarne Kvinge ba072d3168 [mtouch] Mark all public types in the root assemblies when in embeddinator mode.
Otherwise the linker might remove root assemblies, if they're libraries and
nothing at all is marked in them.
2017-04-18 11:36:30 +02:00
Sebastien Pouliot 8ffb553e9e [linker] Capture and show more information when a MT2001 error occurs (#1947) 2017-03-30 14:41:56 -05:00
Rolf Bjarne Kvinge 26aa29ebd0 Merge remote-tracking branch 'origin/master' into mono-2017-02 2017-03-24 18:09:24 +01:00
Marek Safar 60bf37efad Wire up configuration to MonoTouchSweepStep 2017-03-14 11:51:08 +01:00
Rolf Bjarne Kvinge a163cb2e14 [mtouch] Make the linker accept multiple root assemblies. 2017-02-10 16:39:14 +01:00
Rolf Bjarne Kvinge a4dbb289b6 [mtouch] Make the linker output a list of AssemblyDefinition instead of paths.
Have the linker return the paths for AssemblyDefinitions is just redundant if
we immediately use those paths to re-load the AssemblyDefinitions.
2017-02-10 14:12:02 +01:00
Alex Soto 3b0f1baf69 [mmp/btouch] Better error when bad xml linker input is given to mmp/mtouch (#1614)
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=52238

If you give mtouch/mmp a linker xml file with bad input for
example a Xamarin.iOS app and the linker.xml has a reference
to Xamarin.Mac instead of X.I.dll i.e.

<?xml version="1.0" encoding="UTF-8" ?>
<linker>
	<assembly fullname="Xamarin.Mac">
    	<type fullname="ObjCRuntime.Constants"/>
	</assembly>
</linker>

You will get a not so helpful generic error

MT2001 Could not link assemblies. Reason: Failed to process XML description: <unspecified>

It seems that when you use a xml file for linker you get a
`XmlResolutionException` from cecil when it fails to resolve
and the better error comes from the inner exception so we use
that instead.

New error output for XmlResolutionException:

MT2017: Could not process XML description: Failed to resolve assembly: 'Xamarin.Mac, Culture=neutral, PublicKeyToken=null'
2017-02-03 14:04:06 -06:00
Rolf Bjarne Kvinge 2d104f32d9 [mtouch] Make sure native symbols from third-party libraries are preserved in dylibs. Fixes #51548.
The native linker treats object files (.o) and static libraries (.a files,
which are archives of .o files) differently.

The native linker will always include object files into the executable:

	$ echo "void xxx () {}" > foo.m
	$ clang -c foo.m -o foo.o -arch x86_64
	$ ld foo.o -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
	$ nm foo.dylib
	0000000000000fe0 T _xxx

However, if the object file is inside a static library:

	$ echo "void xxx () {}" > foo.m
	$ clang -c foo.m -o foo.o -arch x86_64
	$ ar cru foo.a foo.o
	$ ld foo.a -dylib -o foo.dylib -macosx_version_min 10.12 -arch x86_64
	$ nm foo.dylib
	<no output>

This means that our testing library (libtest.a) which is a fat library of
_object files_, do not show the problems reported in bug #51548.

So:

a) I've fixed the creation of libtest.a to be a fat library of _static
   libraries_. This causes the `FastDev_LinkWithTest` test to fail exactly
   like in bug #51548.

b) I've made mtouch pass `-u <native symbol>` to the native linker, for every
   native symbol referenced in a managed assembly, when creating a dylib.
   Amazingly this seems to work fine even with symbols to Objective-C classes
   (`_OBJC_CLASS_$_<class name>`).

c) This also required adding support for collecting the Objective-C names of
   all managed types registered with Objective-C to the linker. The
   information is already available in the static registrar, but that would
   require us to make sure the static registrar is executed before compiling
   dylibs, which means those two tasks won't be able to run in parallel (also
   there's no guarantee we'll even run the static registrar).

https://bugzilla.xamarin.com/show_bug.cgi?id=51548
2017-01-18 12:33:06 +01:00
Rolf Bjarne Kvinge b4cc60572b [mtouch/mmp] Share code between link contexts. 2017-01-18 10:48:11 +01:00
Sebastien Pouliot 00b1c09acb [linker] Add an well known candidate inliner substep along with tests (#1513)
TL&DR: This is *how* it should be done and tested, it's not complete
(single, simple case) nor the most interesting case ;-)

The trick is to make sure each case is covered by tests so a mono
_bump_ won't give us a BCL that does not conform to what the linker
expect.

What's the impact ?

1. There is the expected reduction of metadata in mscorlib. Since both
   methods don't call other API there's no indirect effect (removal).

--- before	2017-01-15 11:12:44.000000000 -0500
+++ after	2017-01-15 11:12:56.000000000 -0500
@@ -13166,9 +13166,6 @@
 System.Void System.Security.SecurityException::.ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
 System.Void System.Security.SecurityException::.ctor(System.String)
 System.Void System.Security.SecurityException::GetObjectData(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
-System.Boolean System.Security.SecurityManager::CheckElevatedPermissions()
-System.Security.SecurityManager
-System.Void System.Security.SecurityManager::EnsureElevatedPermissions()
 System.Security.SecurityRulesAttribute
 System.Security.SecurityRuleSet System.Security.SecurityRulesAttribute::m_ruleSet
 System.Void System.Security.SecurityRulesAttribute::.ctor(System.Security.SecurityRuleSet)

2. There is no visible size change (even with #1) in mscorlib.dll due to
   padding (compiler /filealign)

   mscorlib.dll                793,600      793,600            0       0.00 %

3. there's a *very* small reduction of mscorlib.*.aotdata size

   mscorlib.armv7.aotdata      717,264      717,216          -48      -0.01 %
   mscorlib.arm64.aotdata      712,840      712,704         -136      -0.02 %

   AOT data *.aotdata        6,460,064    6,459,880         -184       0.00 %

4. there's no change in executable size - normal as the AOT compiler has
   _likely_ already doing the same optimization (before this commit)

   Executable               29,270,272   29,270,272            0       0.00 %

Full comparison: https://gist.github.com/spouliot/0464c8fa3a92b6486dfd90595d9eb718
2017-01-17 21:49:44 -05:00
Sebastien Pouliot 0a25188751 [mtouch] Remove RemoveSelector step for XI (#1512)
We're not storing selectors in fields anymore so this step does nothing
expect iterating over the code.

The step is still needed for `mmp` (for Xamarin.Mac.dll)
2017-01-16 14:00:55 -05:00
Rolf Bjarne Kvinge d1102c800e [mtouch] Remove most static state and put it on an instance. (#1398)
* [mtouch] Remove most static state and put it on an instance.

Remove most static state, and put it on an instance (of Application) instead.

Soon we'll build multiple apps (app extensions) in the same process, and we
need to make sure we're not inadvertedly (and incorrectly) sharing state
between apps, so remove as much static state as possible to avoid any
problems.

* [mtouch] Rename GetIsUsingClang -> IsUsingClang.
2016-12-23 18:50:35 +01:00
Sebastien Pouliot c92934eb6d [mtouch][mmp] Only allow `appletls` for the TLS provider (#1132)
The old `legacy` option will now be reported as a warning. 

That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE). 

This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls

Note: The BCL changes will happen in later stages.
2016-11-08 14:42:40 -05:00
Sebastien Pouliot 7b38187479 [mtouch][mmp] Unify user resources removal as a link step (#1026)
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.

The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.

E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites

mtouch (before)
		Total time: 64202 ms

mtouch (after)
		Total time: 34840 ms

* Add XM support for RemoveUserResourcesSubStep

* Tests supplied by @chamons
2016-11-01 13:11:25 -04:00
Rolf Bjarne Kvinge 0fa4235097 [mtouch] Don't do any TLS processing in the linker for watchOS.
Don't do any TLS processing in the linker for watchOS, because on watchOS we
don't have (managed) TLS.
2016-10-03 18:31:04 +02:00
Rolf Bjarne Kvinge 0863e412b4 Remove XI/Classic support (#926)
* [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.
2016-09-30 15:02:17 -04:00
Rolf Bjarne Kvinge 2eb6ba12c7 [mtouch/mmp] Fix build after breaking cecil update in mono.
Also use mono's cecil instead of our own cecil submodule for mtouch.
2016-09-01 18:28:35 +02:00
Rolf Bjarne Kvinge e291f1717d Revert "Bump [watch-]mono to master to get fix for #43658." (#665) 2016-08-25 14:44:53 +02:00
Rolf Bjarne Kvinge f6b1ccd748 Bump [watch-]mono to master to get fix for #43658. (#653)
* Bump [watch-]mono to master to get fix for #43658.

https://bugzilla.xamarin.com/show_bug.cgi?id=43658

* [mtouch/mmp] Fix build after breaking cecil update in mono.

Also use mono's cecil instead of our own cecil submodule for mtouch.

* Bump [watch-]mono to get compilation fixes after cecil bump in mono.

* Remove cecil submodule, we only use the one in mono now.
2016-08-25 13:10:14 +02:00
Rolf Bjarne Kvinge 1f1f6991a3 Implement support for exception marshalling. 2016-05-17 11:23:48 +02:00
Rolf Bjarne Kvinge 50a8af84db Add mtouch to the build. 2016-04-24 14:47:27 -04:00