The macOS arm64 was using a new mechanism to implement FlushProcessWriteBuffers
because the original one based on a wired memory page doesn't work on arm64.
We have seen people hitting problems with the wired memory page allocation on
x64 in the past due to the fact that wired memory is a scarce resource and
in some cases, e.g. in presence of apps that greedily grab all of the available
wired memory pages, we were unable to initialize coreclr and execute any .NET
application.

This change switches x64 to the same mechanism as arm64 to prevent that issue
from happening and updates the minimum supported x64 macOS to 10.14. That's the
version required for the new APIs the change is using. Apple stopped supporting
10.13 a year ago anyways.

* Have more concise check for "HFAs should not be morphed to FieldList when they are not passed on SIMD registers" in src/coreclr/jit/morph.cpp

* Pass HFA/HVA arguments in registers in src/coreclr/jit/morph.cpp

It is not used on arm32/arm64.

Co-authored-by: NJan Kotas <jkotas@microsoft.com>

Fixes: https://github.com/dotnet/runtime/issues/56163

PR #58523 fixed something on Windows, but it didn't actually address
our issues on Android.

A directory name like `foo Ümläüts` fails:

* `mkdir 'foo Ümläüts' ; cd 'foo Ümläüts'`
* `dotnet new android`
* `dotnet build -c Release -p:RunAOTCompilation=true` (adding
  `-p:EnableLLVM=true` complicates further)

The error:

    Precompiling failed for C:\src\foo Ümläüts\obj\Release\android-arm64\linked\System.Private.CoreLib.dll: Error: Loaded assembly 'C:\src\foo ├£ml├ñ├╝ts\obj\Release\android-arm64\linked\System.Private.CoreLib.dll' doesn't match original file name 'C:\foo ▄mlΣⁿts\obj\Release\android-arm64\linked\System.Private.CoreLib.dll'. Set MONO_PATH to the assembly's location.

Reviewing the existing AOT implementation in Xamarin.Android, I found
out *why* Xamarin.Android works:

    [AOT] response file obj\Release\120\aot\arm64-v8a\App36.dll\response.txt: --llvm "--aot=temp-path=obj\Release\120\aot\arm64-v8a\App36.dll,llvm-path=C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Xamarin\Android,outfile=obj\Release\120\aot\arm64-v8a\libaot-App36.dll.so,msym-dir=obj\Release\120\aot\arm64-v8a,asmwriter,mtriple=aarch64-linux-android,tool-prefix=C:\Program Files (x86)\Android\android-sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\aarch64-linux-android-,ld-name=ld.EXE,ld-flags=\"-LC:\Program Files (x86)\Android\android-sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\lib\gcc\aarch64-linux-android\4.9.x\";\"-LC:\Program Files (x86)\Android\android-sdk\ndk-bundle\platforms\android-21\arch-arm64\usr\lib\";\"C:\Program Files (x86)\Android\android-sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\lib\gcc\aarch64-linux-android\4.9.x\libgcc.a\";\"C:\Program Files (x86)\Android\android-sdk\ndk-bundle\platforms\android-21\arch-arm64\usr\lib\libc.so\";\"C:\Program Files (x86)\Android\android-sdk\ndk-bundle\platforms\android-21\arch-arm64\usr\lib\libm.so\"" C:\Users\jopepper\source\repos\App36\App36\obj\Release\120\android\assets\shrunk\App36.dll

1. Xamarin.Android passes *relative* paths. The `foo Ümläüts`
   directory name doesn't even come into play for some arguments.

2. With LLVM, `ld-flags` contains a `;`.

The existing code splits on `;` and joins on `,`:

https://github.com/dotnet/runtime/blob/25c207351c4f57cf2daa98caaf327a8b8d83edb8/src/tasks/AotCompilerTask/MonoAOTCompiler.cs#L505-L509

So we lose any `;` delimiters for the `ld-flags` value, they get
replaced by `,`.

I think the solution here is:

1. Add several missing properties to `<MonoAOTCompiler/>` so we don't
   have to rely on the `%(AotArguments)` item metadata. No splitting
   on `;` would be required, `ld-flags` can be passed in and used as-is.

2. Add a new `WorkingDirectory` property. When this is set, assume
   paths passed in might be relative -- and don't transform paths by
   calling `Path.GetFullPath()`.

Lastly, I fixed a place where the UTF8 encoding wasn't passed when
MSBuild logging the response file.

These changes I tried to make in a way where this shouldn't break
other .NET workloads like wasm. If existing MSBuild targets call this
task (not using the new properties), the behavior should remain
unchanged.

I tested these changes by commiting a modified `MonoAOTCompiler.dll`:

https://github.com/xamarin/xamarin-android/pull/6562

I'm able to enable several AOT tests related to dotnet/runtime#56163.

* Update libunwind to v1.6.2

* Apply libunwind changes from 1b5719c2Co-authored-by: NJan Vorlicek <janvorli@microsoft.com>

* Suppress Wincompatible-pointer-types on arm64

* Fix remote unwinding on win-arm64

* Mark base as both input and output
Co-authored-by: NJan Vorlicek <jan.vorlicek@volny.cz>
Co-authored-by: NJan Vorlicek <janvorli@microsoft.com>
Co-authored-by: NJan Vorlicek <jan.vorlicek@volny.cz>

* Fix 62551

* Addressing @radical comments.

* Adding comments to not forget what we were trying to test.
Indenting.

* Improved ARM64 disassembly by emitting the right register

* Assume INS_OPTS_NONE and INS_OPTS_LSL are 64bit when displaying an extended register

We'll probably want to spread these out to the appropriate categories (CoreMangLib, etc.) and enable them for non-NativeAOT scenarios eventually. For now, moving these as they were in runtimelab because being able to build them as a subtree (`build.sh tree nativeaot`) in one go makes things easy.

This partially reverts this change: https://github.com/dotnet/runtime/pull/62652

The problem is that although we no longer need to patch, we do need corerun from the clr.hosts subset. Corerun still ends up as part of the pubished clr product artifact, and not in the mono product artifact. And thus we still end up downloading clr, and still need this dependency for now.

* [mono] Fix types for arguments to printf calls

   These came up while I was using a code scanning tool.

* Fix build

Co-authored-by: NJamesNK <JamesNK@users.noreply.github.com>

This is similar in spirit to the static library for the single file host.

The main different from the single file host one is that we don't want `/GL` because the static library is going to be linked on end user machine and `/GL` is super version fragile.

We build two flavors - with control flow guard and without control flow guard. CFG is a compile time option for end users in NativeAOT and we need static libs that support both.

The issue seems to be caused by a bug in the test. The problematic call
to `TestCreateMutex` is passed `nullptr` as the `name` parameter. It
then calls `convert` helper on it to convert it to wide char. However,
the `convert` helper doesn't check whether it is `nullptr` or not and
ends up returning a pointer to a memory with possibly random data,
that is returned by `malloc(0)`. The returned pointer is then passed to
the CreateMutex PAL api that probably ends up attempting to get the
length of the name or something. And depending on the random data, it
sometimes fails.

The fix is to change the `convert` function to handle `nullptr` so that
it returns `nullptr` too.

Tracking: #62423

Fixing regression for AuthType.Anonymous  which leads to a NullReferenceException be thrown. (#62807)

This group comprises a C# & IL main module and a C# & IL library
and tries all four pairings between them. The C# version of the
main module used to be shared but that's problematic with test
merging as distinguishing the two tests with an identical
namespace, class name and entry point would be hard. As this is
the only occurrence of this pattern in the runtime test source
tree, I'm proposing to duplicate the C# main module source and
adjust it for the two scenarios (targeting C# vs. IL version
of the dependent library).

Thanks

Tomas

Co-authored-by: Ndotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

- The page size is different between arm64 processes and emulated x64 processes
- The shared memory file size is set to the page size and there was a strict check on the file size, leading to an exception from the second process of a different arch that tries to share the same mutex
- Made the file size check less strict, and allowed an arch to increase but not decrease the file size such that it can be mapped at page size granularity
- Fix for https://github.com/dotnet/runtime/issues/62140 in main

Co-authored-by: NJames Newton-King <james@newtonking.com>

I have identified 63 tests in the tree that set IlasmRoundTrip
to true in their MSBuild project scripts. I haven't found any place
in the scripts that would be looking at the value so I'm guessing
it may have been a predecessor to today property
IlasmRoundTripIncompatible and I'm proposing to delete the unused
property. Please let me know if you're aware of any test script logic
that queries it.

Thanks

Tomas

The top level `Directory.Build.props` imports eng/native/naming.props,
which defines platform specific naming conventions. Use that in places
where locally defined props are used and delete the redundant props.

* removed IMAGE_MAPPED

* removed RawImageLayout

* delete MappedImageLayout

* use mem-mapping on Windows

* tweaks and touchups

* a few cleanups

* comments

* move EnsureLoaded into Assemby::Init

* A fix for IsDynamic() case.

* fix for preferred base, if used.

* disable failing scenario

* PR feedback

* Typo (CENTINEL --> SENTINEL)

* added a bug link to a disabled test scenario + couple comment tweaks

- eliminate slow ArgsMarshalString
- make rollup build incremental
- exclude dotnet.d.ts from typescript inputs

* Remove AOT warnings for S.Drawing.Common
- `Marshal.SizeOf(Type)` replaced with `Marshal.SizeOt<T>()`
- `Marshal.PtrToStructure(IntrPtr, Type)` replaced with `Marshal.PtrToStructure<T>(IntPtr)`

* Use pointers where possible

* Ref return PRINTDLG

* Use GeneratedDllImport
Co-authored-by: NJan Kotas <jkotas@microsoft.com>

* Avoiding assert on mono runtime

* Update src/mono/wasm/debugger/BrowserDebugProxy/DebugStore.cs
Co-authored-by: NAnkit Jain <radical@gmail.com>

* Addressing @radical comments.
Removing unused fields in another test case.
Co-authored-by: NAnkit Jain <radical@gmail.com>

* [tests] Re-enable some explicit layout tests on Mono

   These were fixed by https://github.com/dotnet/runtime/pull/61467

   Related to https://github.com/dotnet/runtime/issues/36112

* objref and non-objref overlap tests expected to fail AOT compilation

   As well as the NestedStructs tests.

   Resolves https://github.com/dotnet/runtime/issues/62567