Merge pull request #2543 from ermshiperete/Xamarin-31021

Don't ignore drives with type "aufs" or "overlay" (Xamarin-31021)

Merge pull request #2757 from akoeplinger/fix-coreclr-test

Two coreclr test fixes

Fix the build.

[corlib] Fix Delegate.Combine() to throw on non-matching types

This was inadvertently removed in https://github.com/mono/mono/commit/611a43ee0f672adbac3e25dc77731843a3d10cf1 from MulticastDelegate.CombineImpl().

Add the type check back in the Delegate base class, we already do the same in Remove().

Add unit tests to cover the behavior to the corlib test suite. (reverted from commit f29878dc713f4e148fe0a1e703fae8929e6fb6e0)

Needed to update some monodoc tests to match that an exception is now thrown again.

Merge pull request #2755 from xmcclure/disable-omit-fp

"disable_omit_fp" option for MONO_DEBUG

Merge pull request #2750 from radical/tasklogger

[xbuild] TaskLoggingHelper: Implement support for correctly using tas…

[xbuild] TaskLoggingHelper: Implement support for correctly using task resources

- make task resources available to TaskLoggingHelper
- verify TaskLoggingHelper method args
- tests

[jit] Remove some loader error usage.

[corlib] Fix UIntPtr.ToString() 64bit implementation

Cast to ulong instead of uint, this is also what referencesource does:
https://github.com/Microsoft/referencesource/blob/d925d870f3cb3f6acdb14e71522ece7054e2233b/mscorlib/system/uintptr.cs#L114-L122

Also bump coreclr submodule to bring in another UIntPtr fix.

[mcs] Better check for automatically implemented property inside a type with an explicit StructLayout. Fixes #39574

[system.net.http] The backslash character may be used as a single-character quoting mechanism within quoted-string. Fixes #39569

Fix the build.

Merge pull request #2754 from markusbeth/fix-mono-config

fixed replacement of $mono_libdir in config file

strncpy does not NUL-terminate the destination string in this case so one cannot use strcat to append

This fixes the error "malloc: top chunk is corrupt" as reported on mono-devel-list back in 2015-10-20 (subject: "malloc error executing OBS-built mono") at least for me.

Merge pull request #2756 from vargaz/llvm-jit-3.9

[llvm] Finish JIT support for llvm 3.9.

[llvm] Finish JIT support for llvm 3.9.

[mono-config] fix copying of prefix during replacement

[acceptance-tests] Bump coreclr and ms-test-suite to bring in some fixes

Also disable a test that makes no sense.

Merge pull request #2752 from kumpera/the_loader_error_highlander

This removed the last source of loader error from the runtime

The last source was on the AOT compiler in load_image.

I hooked enough MonoError to bubble the issue to a reasonably higher layer.

@vargaz please review.

fixed more srtncpy bugs

Merge pull request #2740 from lambdageek/dev/monoerror-reflection-icalls1

[reflection] MonoError for a few icalls

Merge pull request #2739 from lambdageek/dev/monoerror-type_load_class

[MonoError] Use class name for mono_error_set_type_load_class() exceptions

[aot] Load errors in mono_aot_get_method_from_vt_slot must not be fatal as failed slots will simply use the JIT.

[xbuild] Remove ErrorTest.TestExecute1()

This was an incorrect test. Tasks can't really be used like this
especially this once since it tries to Log an error, but it hasn't been
assigned a BuildEngine yet!

Other fixes in TaskLoggingHelper expose this issue.

"disable_omit_fp" can now be included in MONO_DEBUG

Option disables a compiler optimization that omits framepointers from the stack.

Merge pull request #2751 from akoeplinger/fix-msbuild-remapping

Fix msbuild remapping

First commit:
```
Revert "Do not remap framework assembly if it's version is higher than the runtime version"

It would cause issues on mobile, cause the runtime version is 2.0.5.0 there and loading
e.g. System.dll v4.0 would no longer be mapped to that version anymore after this change.
```
---
Second commit:
```
[runtime] Stop remapping higher versions of
 Microsoft.Build.Framework/Engine and remap Microsoft.Build.Utilities/Tasks
 (.v3.5)

The previous remapping was added in 725ed3f82400b1466ca17e99b85adcbde54238ca, but it didn't actually
fix the bug in https://bugzilla.xamarin.com/show_bug.cgi?id=32561.

The underlying cause of the bug is that in Mono 4.0 we removed the 2.0/3.5 profiles.
This meant that Microsoft.Build.Utilities.dll and Microsoft.Build.Utilities.v3.5.dll weren't installed
in the GAC anymore, because MSBuild 4.0 uses Microsoft.Build.Utilities.v4.0.dll, so the app failed
to load the 2.0 version of the assembly. The same applies for the .Tasks variants.

We remap earlier versions of the Microsoft.Build.Utilities/Tasks assemblies to the v4.0 version.
I've introduced another item in the AssemblyVersionMap struct which allows remapping to target a different
assembly name, because MSBuild made the questionable decision to put the version number in the assembly name.
While strictly speaking this is not what .NET is doing (it just fails there if .NET 2.0 isn't installed)
on Mono there's no way to install those older profiles anymore, so we remap them to v4.0 to keep apps working.

Newer versions of Microsoft.Build.Framework/Engine (like 12.0, 14.0) however have the same name, so we need to be
more careful here and only do a remapping to the 4.0 version if it's an earlier version (e.g. 2.0 -> 4.0).
This avoids issues with accidentally remapping 14.0 -> 4.0.

I tested the app from the bug report and it now works fine.
```

[runtime] Stop remapping higher versions of Microsoft.Build.Framework/Engine and remap Microsoft.Build.Utilities/Tasks (.v3.5)

The previous remapping was added in 725ed3f82400b1466ca17e99b85adcbde54238ca, but it didn't actually
fix the bug in https://bugzilla.xamarin.com/show_bug.cgi?id=32561.

The underlying cause of the bug is that in Mono 4.0 we removed the 2.0/3.5 profiles.
This meant that Microsoft.Build.Utilities.dll and Microsoft.Build.Utilities.v3.5.dll weren't installed
in the GAC anymore, because MSBuild 4.0 uses Microsoft.Build.Utilities.v4.0.dll, so the app failed
to load the 2.0 version of the assembly. The same applies for the .Tasks variants.

We remap earlier versions of the Microsoft.Build.Utilities/Tasks assemblies to the v4.0 version.
I've introduced another item in the AssemblyVersionMap struct which allows remapping to target a different
assembly name, because MSBuild made the questionable decision to put the version number in the assembly name.
While strictly speaking this is not what .NET is doing (it just fails there if .NET 2.0 isn't installed)
on Mono there's no way to install those older profiles anymore, so we remap them to v4.0 to keep apps working.

Newer versions of Microsoft.Build.Framework/Engine (like 12.0, 14.0) however have the same name, so we need to be
more careful here and only do a remapping to the 4.0 version if it's an earlier version (e.g. 2.0 -> 4.0).
This avoids issues with accidentally remapping 14.0 -> 4.0.

I tested the app from the bug report and it now works fine.

fixed replacement of $mono_libdir in config file

strncpy does not terminate the destination string in this case so one
cannot use strcat to append

[System] Bump CTS timeout in BlockingCollectionTests

Saw a few failures on Jenkins on the slower ARM machines over the last days:

```
) MonoTests.System.Collections.Concurrent.BlockingCollectionTests.AddAnyCancellable : System.OperationCanceledException : The operation was canceled.
at System.Collections.Concurrent.BlockingCollection`1[T].TryAddToAnyCore (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, Int32 millisecondsTimeout, CancellationToken externalCancellationToken) [0x00092] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/external/referencesource/System/sys/system/collections/concurrent/BlockingCollection.cs:1041
at System.Collections.Concurrent.BlockingCollection`1[T].TryAddToAny (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, Int32 millisecondsTimeout, CancellationToken cancellationToken) [0x00006] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/external/referencesource/System/sys/system/collections/concurrent/BlockingCollection.cs:971
at System.Collections.Concurrent.BlockingCollection`1[T].AddToAny (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, CancellationToken cancellationToken) <0x4421bf18 + 0x0002b> in <filename unknown>:0
at MonoTests.System.Collections.Concurrent.BlockingCollectionTests.AddAnyCancellable () [0x00031] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/mcs/class/System/Test/System.Collections.Concurrent/BlockingCollectionTests.cs:276
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003d] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/mcs/class/corlib/System.Reflection/StrongNameKeyPair.cs:103
```

100ms is likely just too short, bumping it.

Merge pull request #2749 from BrzVlad/fix-suspend-deadlock

[runtime] Fix deadlock while unwinding the stack of suspended thread

A suspended thread, in non-coop case, can be holding runtime locks. When the suspender tries to unwind the stack for this thread, it might require taking of runtime locks (ex. in aot case we might search for the jit info in the aot image and then register it, which requires the domain lock). Mark the suspender thread as running in async context while it unwinds other threads.

[aot] Add MonoError to decode_method_ref.

[aot] Add MonoError to decode_method_ref_with_target.

[aot] Introduce MonoError in decode_resolve_method_ref.

Revert "Do not remap framework assembly if it's version is higher than the runtime version"

This reverts commit 100bd760a46811121b4b47ebba941d4fb98486ab.

It would cause issues on mobile, cause the runtime version is 2.0.5.0 there and loading e.g. System.dll v4.0 would
no longer be mapped to that version anymore after this change.

[aot] Introduce MonoError in decode_generic_context.

[aot] Add MonoError to load_image.

[aot] Wire up MonoError into decode_klass_ref, decode_type and decode_generic_inst.

[runtime] Fix monodroid build

Merge pull request #2744 from akoeplinger/convert-fixes

[corlib] Fix Convert.ToUInt32 not throwing OverflowException with a too large number

[mcs] Codegen update for specialized struct initialization with awaited element initializer. Fixes #39459

[tests] Add test for assembly remapping change from 100bd760a46811121b4b47ebba941d4fb98486ab

Testing for the remap message via grep isn't ideal, a better way to verify the assembly
version would be to check asm.GetName().Version, but unfortunately in the test environment
when MONO_PATH is set the assembly loading always fallsback to a simple file name matching
in the directory so we end up with the wrong (v4.0) assembly in that case.

Merge pull request #2733 from ludovic-henry/fix-mono_cpu_count

[utils] Make distinction between configured and online CPU count

[jit] Add a separate header file for llvm-jit.cpp.

[corlib] Fix Convert.ToUInt32 not throwing OverflowException with a too large number

This was revealed by the CoreCLR tests/src/CoreMangLib/cti/system/convert/converttouint3219.exe test.

When we tried to convert a number larger than UInt32.MaxValue (in this case 4933891728) we would cast
the intermediate result to uint which overflows and makes the end result smaller which means we don't throw.

Storing the intermediate result in a long before checking for the correct range fixes this.

Added a few additional tests that I felt were missing and/or only present for other Convert.* methods.
I found two more cases that don't throw OverflowException but fixing it looked more involved so I punted
and just ignored them with a FIXME for now.

[utils] Make distinction between ARM platforms for CPU count

ARM platform tends to try very hard to save power by switching off CPUs. This could lead to inconsistencies in the value returned by mono_cpu_count

Recap from Alexander Köplinger <alex.koeplinger@outlook.com>:

When we merged the change from PR #2722, we started seeing random failures on ARM in the MonoTests.System.Threading.ThreadPoolTests.SetAndGetMaxThreads and MonoTests.System.Threading.ManualResetEventSlimTests.Constructor_Defaults tests. Both of those tests are dealing with Environment.ProcessorCount to verify some implementation details.

It turns out that on the Jetson TK1 board we use on public Jenkins and on ARM kernels in general, the value returned by sched_getaffinity (or _SC_NPROCESSORS_ONLN) doesn't contain CPUs/cores that are powered off for power saving reasons. This is contrary to what happens on x86, where even cores in deep-sleep state are returned [1], [2]. This means that we would get a processor count of 1 at one point in time and a higher value when load increases later on as the system wakes CPUs.

Various runtime pieces like the threadpool and also user code however relies on the value returned by Environment.ProcessorCount e.g. for deciding how many parallel tasks to start, thereby limiting the performance when that code thinks we only have one CPU.

Talking to a few people, this was the reason why we changed to _SC_NPROCESSORS_CONF in https://github.com/mono/mono/pull/1688 and why we added a special case for Android in https://github.com/mono/mono/commit/de3addcde5bf875dcd43d3e2c6536d61871e7675 to get the "real" number of processors in the system.

Because of those issues Android/Dalvik also switched from _ONLN to _SC_NPROCESSORS_CONF for the Java API Runtime.availableProcessors() too [3], citing:
> Traditionally this returned the number currently online,
but many mobile devices are able to take unused cores offline to
save power, so releases newer than Android 4.2 (Jelly Bean) return the maximum number of
cores that could be made available if there were no power or heat
constraints.

The problem with sticking to _SC_NPROCESSORS_CONF however is that it breaks down in constrained environments like Docker or with an explicit CPU affinity set by the Linux `taskset` command, They'd get a higher CPU count than can be used, start more threads etc. which results in unnecessary context switches and overloaded systems. That's why we need to respect sched_getaffinity.

So while in an ideal world we would be able to rely on sched_getaffinity/_SC_NPROCESSORS_ONLN to return the number of theoretically available CPUs regardless of power saving measures everywhere, we can't do this on ARM.

I think the pragmatic solution is the following:
* use sched_getaffinity (+ fallback to _SC_NPROCESSORS_ONLN in case of error) on x86. This ensures we're inline with what OpenJDK [4] and CoreCLR [5] do
* use _SC_NPROCESSORS_CONF exclusively on ARM (I think we could eventually even get rid of the PLATFORM_ANDROID special case)

Thoughts?

Helpful links:

[1] https://sourceware.org/ml/libc-alpha/2013-07/msg00383.html
[2] https://lists.01.org/pipermail/powertop/2012-September/000433.html
[3] https://android.googlesource.com/platform/libcore/+/750dc634e56c58d1d04f6a138734ac2b772900b5%5E1..750dc634e56c58d1d04f6a138734ac2b772900b5/
[4] https://bugs.openjdk.java.net/browse/JDK-6515172
[5] https://github.com/dotnet/coreclr/blob/7058273693db2555f127ce16e6b0c5b40fb04867/src/pal/src/misc/sysinfo.cpp#L148

[build] Define HOST_* architecture

Merge pull request #2732 from radical/asm_remap

Do not remap framework assembly if it's version is higher than the ru…

…ntime version

Currently, assemblies like Microsoft.Build.Framework and
Microsoft.Build.Engine get remapped to the current runtime version, at
load time. This means that if an assembly references the above
assemblies with a version like `14.1.0.0`, then that would get remapped
to `4.0.0.0`. This is incorrect behavior and breaks msbuild. Instead,
now we do the remapping only if the requested version is lower than the
runtime version.

Merge pull request #2741 from akoeplinger/acceptance-tests-split

A few improvements to acceptance-tests

Merge pull request #2743 from qmfrederik/fixes/complete-eventsource-3

System.Diagnostics.Tracing: Add EventListener and related classes

[xbuild] Remove explicit warning level set when csproj does not have it and leave the default to compiler

[runtime] Fix deadlock while unwinding the stack of suspended thread

A suspended thread, in non-coop case, can be holding runtime locks. When the suspender tries to unwind the stack for this thread, it might require taking of runtime locks (ex. in aot case we might search for the jit info in the aot image and then register it, which requires the domain lock). Mark the suspender thread as running in async context while it unwinds other threads.

Do not remap framework assembly if it's version is higher than the runtime version

Currently, assemblies like Microsoft.Build.Framework and
Microsoft.Build.Engine get remapped to the current runtime version, at
load time. This means that if an assembly references the above
assemblies with a version like `14.1.0.0`, then that would get remapped
to `4.0.0.0`. This is incorrect behavior and breaks msbuild. Instead,
now we do the remapping only if the requested version is lower than the
runtime version.

@akoplinger: This will actually impact xbuild too right now because
we're defaulting to xbuild 14.0 in Mono 4.4 now so we'd see messages
like Mono: The request to load the assembly Microsoft.Build.Framework
v14.0.0.0 was remapped to v4.0.0.0 in the assembly loading log, which
will break in very subtle ways.

Bump ikdasm

System.Diagnostics.Tracing: Add EventListener and related classes

Merge pull request #2742 from mono/revert-2738-fixes/complete-eventsource-2

Revert "Add EventListener and EventListenerEventArgs to Mono"

Revert "Add EventListener and EventListenerEventArgs to Mono"

[acceptance-tests] Better description in readme

Merge pull request #2738 from qmfrederik/fixes/complete-eventsource-2

Add EventListener and EventListenerEventArgs to Mono

[acceptance-tests] Stop symlinking System.Console.dll facade

It should no longer be required after 6e81edfa241bedbb3971ca1e7aece82f31de54c1.

[acceptance-tests] Split the test suites out of Makefile.am into own files

[mcs] nameof operator can use static member. Fixes #39455

[reflection] Use MonoError in mono_reflection_get_token

Mark it external only.  Runtime should use mono_reflection_get_token_checked.

[reflection] Add MonoError-ized mono_reflection_get_type_checked

Mark mono_reflection_get_type external only.

[MonoError] Use class name for mono_error_set_type_load_class() exceptions

If MONO_ERROR_TYPE_LOAD is set and there's a error->exn.klass available,
try to grab the type name from the klass when preparing an exception.

[llvm] Add beginnings of JIT support for LLVM > 3.9.

[acceptance-tests] Move git "submodules" to acceptance-tests/external instead of next to Mono repo

A few people told me it's surprising that acceptance-tests checks out repos into <mono repo>/../
and it can cause unwanted changes when a repo with the same name already exists there.

While this structure is used in several internal repos I agree for Mono it's better to keep
everything inside the repo itself.

[reflection] MonoError in mono_method_body_get_object

Mark it external only.  Runtime should use mono_method_body_get_object_checked

[aot] Fix a buffer overflow in the statistics code.

[runtime] Remove some unused code.

Remove #if NET_4_6

Remove conditional compilation statement as per PR feedback

Merge pull request #2736 from xmcclure/more-trampolines

Increase default number of aot-compile trampolines

The current defaults are not enough to successfully run
`make fullaotcheck` in mono/mini

Merge pull request #2735 from xmcclure/early-lookup-addr

Early ICALL_ADDR lookup on pinvoke to fix checked-build assert

The pinvoke implementation in the failure case was creating a managed
exception object while in blocking mode, a rules violation. This patch
puts a redundant lookup early so that any exceptions occur before
blocking mode is entered. (The "real" lookup is unchanged because the
current pattern is optimized well by the JIT.)

Merge pull request #2731 from Phyyl/master

Remove throw statement in IPAddress.TryParse

In Microsoft's implementation, no exceptions are thrown in this particular method. See here for details: http://referencesource.microsoft.com/#System/net/System/Net/IPAddress.cs,54a3a3f536d5a22c

Merge pull request #2674 from lambdageek/dev/monoerror-mono_field_get_value_object

Use MonoError for mono_field_get_value_object

Mark it external only.  Runtime should use mono_field_get_value_object_checked.

Increase default number of aot-compile trampolines

The current defaults are not enough to successfully run
`make fullaotcheck` in mono/mini

Merge pull request #2718 from lambdageek/dev/monoerror-sre

[System.Reflection.Emit] Use MonoError in static functions

Fix an assert in checked-build GC mode

The pinvoke implementation in the failure case was creating a managed
exception object while in blocking mode, a rules violation. This patch
puts a redundant lookup early so that any exceptions occur before
blocking mode is entered. (The "real" lookup is unchanged because the
current pattern is optimized well by the JIT.)

[runtime] Fix the support for coop in managed-native wrappers by finishing blocking inside the try clause before converting the result, and only unblocking in the finally clause if we didn't unblock in the try clause.

Added null check in IPAddress.Parse
This check was previously handled in the IPAddress.TryParse method but, but the latter never throws anymore

Merge branch 'master'

[SRE] MonoError in mono_image_emit_manifest

[SRE] MonoError in mono_image_fill_export_table

[SRE] MonoError in mono_image_get_array_token

[SRE] MonoError in mono_image_get_sighelper_token

[SRE] MonoError in mono_image_get_generic_field_token

[SRE] MonoError in add_custom_modifiers

[SRE] MonoError in create_generic_typespec

[SRE] MonoError in mono_image_get_field_on_inst_token

[SRE] MonoError in encode_constraints

[SRE] MonoError in mono_image_get_event_info

[SRE] MonoError in property_encode_signature

[SRE] MonoError in mono_image_get_field_info

[SRE] MonoError in encode_marshal_blob

[SRE] MonoError in field_encode_signature

[SRE] MonoError in method_encode_clauses

[SRE] MonoError in encode_locals

[SRE] MonoError in encode_reflection_type and encode_custom_modifiers

Merge pull request #2706 from ludovic-henry/fix-unhandledexception

[runtime] Set exit code on unhandled exception even if a managed handler is present

In case we would add a AppDomain.CurrentDomain.UnhandledException callback, we would not exit the VM in case of unhandled exception.
This goes against the expected behaviour, as we should indeed call these managed callbacks in all cases, but they should not stop the VM from exiting.

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

Merge pull request #2634 from ludovic-henry/coop-fix-managed-to-native

[coop] Fix managed-to-native wrapper

[runtime] Use MonoError in mono_field_get_value_object

Mark it external only.  Runtime should use mono_field_get_value_object_checked.

Embedded API. Fix method signature match failure for generic types with multiple type parameters.

Details are on the list.
http://mono.1490590.n4.nabble.com/Re-Embedded-API-ctor-method-signature-query-mono-td4667551.html

Robert Jordan said:

It looks like a bug in mono_method_desc_new ():

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378

The function is treating

.ctor(System.Func`2<string, string>)

like a method with 2 arguments:

arg0 = System.Func`2<string
arg1 = string>

This is obviously wrong :)

The function is then storing the (wrong) argument count
for optimization purposes, and the comparison of methods
is starting to fail.