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

* OSR support for Arm64

Enable OSR for Arm64:
* rename `FpToSpDelta` in `PatchpointInfo` to `TotalFrameSize` so it makes
sense for both x64 and Arm64.
* make it clear that the local offsets in `PatchpointInfo` are virtual
(relative to the top of the frame). Adjust recorded Arm64 offsets to match.
* add new jit config setting `JitEnableOSRRange` to allow selectively enabling
OSR for only a subset of jitted methods.
* Arm64 OSR method is passed Tier0 SP but not Tier0 FP, as Tier0 FP can point
either at top or bottom of Tier0 frame depending on frame type. For Arm64 the
OSR method establishes its own FP that chains to caller FP. (I will likely
revise x64 to work this way too, as it makes simple FP chain stackwalks work
out better).
* The Arm64 OSR epilog gets an extra SP adjustment to remove the Tier0 frame.
* The Arm64 OSR prolog gets a phantom SP adjustment in unwind to account for
being passed the Tier0 SP.
* pad OSR funclet frames with tier0 frame size so `PSPSym` ends up at the same
caller-SP relative offset as the OSR frame
* handle the large `fiSpDelta1` offsets from the funclet frame padding 
* local/arg init for the OSR frame from the Tier0 frame was moved into a new
method `genEnregisterOSRArgsAndLocals`; implemented the ARM64 version.
* sequencing of this initialization in the prolog reordered slightly to prevent
inadvertent clobbering.
* comments/code that referred to `original` or `old` method were revised to
instead try and consistently use `tier0`.
* support the mixed-altjit case for OSR by allocating a local copy of the
patchpoint info with similar and plausible information.
* add symbol table note for locals in OSR methods that live on the Tier0 frame.
* fix `fgIsThrowHlpBlk` when called on an empty block
* broaden the jit-experimental testing matrix to include Arm64.

Disable some suspicious tests which might lead to OOM crashes on Android emulators and arm64 devices (#62767)

Just blindly disabling several crypto tests near which crashes have been observed for a while (based on a couple of the mobile targets rolling build runs). 

Disabled tests:

- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteDiminishedDPPrivatePkcs1
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadEncryptedDiminishedDP_EmptyPassword
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Rsa.Tests.RSAKeyFileTests.ReadWriteRsa2048EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.Dsa.Tests.DSAKeyFileTests.cs.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Dsa.TestsDSAKeyFileTests.cs.ReadWriteDsa1024EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.Tests.ECKeyFileTests.DecryptPkcs12PbeTooManyIterations
- System.Security.Cryptography.Tests.ECKeyFileTests.ReadWriteEc256EncryptedPkcs8_Pbes2HighIterations
- System.Security.Cryptography.EcDsa.Tests.ECDsaTests_Span


See also https://github.com/dotnet/runtime/issues/62547.

Iteration count was dropped to a smaller number in https://github.com/dotnet/corert/pull/2867. Looks like it's not enough because we see this test fail in the CI.

Every unwind fragment should be non-zero sized. If we consider
splitting on a boundary that would create a zero-sized fragment,
don't report that one. This only occurs when setting the
stress mode JitSplitFunctionSize to something small.

* Fix duplicated FldSeq in block morphing

Reusing the address for the first field is problematic as
the first field is likely to be at a zero offset, thus a
zero-offset field sequence will be attached to it, and
subsequent copies of the same tree will pick it up, which
is incorrect.

Fix by reusing the address for the last field instead.

* Add a test

* Add a description of the issue to the test

`<TrimmerRootAssembly Include="myEntrypointAssembly" />` won't actually root anything with IL Linker. NativeAOT would do what it's instructed to do. This is showing up as a difference because the SDK auto-injects this root into all trimmed projects.

* callback to make waiting on module load easier

arithm32_cs_d: duplicate of arithm32_d
arithm32_cs_do: duplicate of arithm32_do

arithm64_cs_d: duplicate of arithm64_d with the only difference
that arithm64_d was Pri1. I have kept arithm64_d (due to the
shorter name) but I deleted the Pri1 specifier.

arithm64_cs_do: duplicate of arithm64_do with the only difference
that aritm64_do was Pri1. I have kept arithm64_d (due to the
shorter name) but I deleted the Pri1 specifier.

gc_nested: duplicate of gc_nested_d
nested: duplicate of nested_d
gcreport: duplicate of gcreport_d
native: duplicate of native_d
virtcall: duplicate of virtcall_d
refanyval: duplicate of refanyval_d

In all five cases I kept the version with _d for symmetry with
the other build options (_do / _r / _ro).

_XAssemblytest1-xassem: duplicate of _XModuletest1_xmod
_XAssemblytest2-xassem: duplicate of _XModuletest2_xmod
_XAssemblytest4-xassem: duplicate of _XModuletest4_xmod

In these three cases I kept the _XModuletest variants that have
compilation files and project references organized as two item groups
that is the most prevalent style in our projects. The _Xmoduletest
variants are apparently missing a boilerplate comment that is of
little use.

Thanks

Tomas

* [wasm] Don't emit warning if runtimeconfig.json cannot be found

Library projects don't have runtimeconfig.json files by default. So,
don't make it a warning. Instead, emit a low importance which might be
useful when debugging.

But library projects can have runtimeconfig.json, like the runtime test
projects. So, don't limit processing that by OutputType.

IOW, if it's found then use it.

* [wasm] Add timestamp to logs

* Download dotnet-install script for installing workloads

Instead of trying to use the script from `.dotnet`, download the script.
`.dotnet` might not exist, for example, when the `global.json` version
matches the system installed one.

* [wasm] WasmAppBuilder: catch UnauthorizedAccessException also

* [wasm] Fix bug in tests

Some helper methods have a `Action<JToken>` parameter. Many tests
pass an async lambda to this, expecting it to get awaited upon.

```csharp
    EvaluateAndCheck (Action<T> locals_fn)
    {
        ...
        locals_fn(); // no await
        ...
    }

    async Task Test()
    {
        EvaluateAndCheck( async (locals) => {
            ...
            CheckNumber(locals, ...);

            await CheckDateTime(locals, ..);
            ...

        } );
    }
```

In the above example, roslyn generates an async-void lambda, so the
compiler never complains about the async lambda being passed.
`EvaluateAndCheck` cannot, and does not await this, but if the lambda happens to
block, then it will return at that point, and the test(calling method) will end,
without ever completing the lambda. And for most tests, the actual
checks are done in that lambda.

This gets hit when `CheckDateTimeValue` tries to fetch properties of a
`DateTime` object. And it started to show up when adding
`ConfigureAwait(false)` to some calls.

* [wasm] Add Wasm.Debugger.Tests wrapper project

This is a proxy/wrapper project for `src/mono/wasm/debugger/DebuggerTestSuite/DebuggerTestSuite.csproj`.

- Building the project as part of the regular browser-wasm build
  presents some issues, because of part the tests need use the aspnet
  sdk, and that doesn't work with `browser-wasm`.
- This wrapper project essentially builds the `DebuggerTestSuite`
  project, with some
  properties(`TargetFramework;TargetFrameworks;Configuration;TargetOS;TargetArchitecture`)
  removed so they don't propogate from the parent build.
  - And it packages it up for running the tests on helix

- I did try to convert `DebuggerTestSuite` into a `Wasm.Debugger.Tests`,
  and make it use the library tests infrastructure, but ran into an
  issue
  - it built the project with no `testhost.dll`, so can't use `dotnet
    test`
  - it did get `xunit.console.dll`, but that would fail to run the tests
    because of missing `System.Runtime` (and I'm guessing, other
    assemblies)
    - attempts to publish the project failed
    - So, for now, this is what we have!

* [wasm][tests] Make them friendly to running outside the tree

.. like on helix.

Add new `DEBUGGER_TEST_PATH`, and `CHROME_PATH_FOR_DEBUGGER_TESTS` which
will be set for helix.

And change the appbundle directory name from the misleading `publish/`
to `AppBundle/`.

* [wasm] Tests.cs -> MiscTests.cs

* [wasm] Add support for submitting debugger tests to helix

Also, added `eng/testing/scenarios/WasmDebuggerTestsJobsList.txt` which
is a manually generated list of test classes. This will be changed to be
generated at runtime, in an upcoming PR.

* [wasm] Add debugger tests job for linux, and windows

They follow the same pattern as other wasm jobs:

- build when isFullMatrix
- build in runtime-manual
- Additionally, build when there are changes in:

```
  - src/mono/wasm/debugger/*
  - src/mono/wasm/runtime/*
  - src/mono/mono/*
```

* [wasm] Add new make targets to submit tests to helix

`submit-debugger-tests-helix`
`submit-tests-helix` - submits any library test archives

* Build Wasm.Debugger.Tests from src/libraries/tests.proj

* DebuggerTestSuite: Copy files for the test archive

* [wasm] Fix HarnessTests.BrowserClose

* [wasm] Fix building `ApplyUpdateReferencedAssembly` project on CI

Essentially, disable use of SourceLink which gets enabled by default
when using `-p:ContinuousIntegrationBuild=true`.

Issue: https://github.com/dotnet/runtime/issues/62618

* cleanup

* Wasm.Build.Tests: add missing file

* [wasm] sendtohelixhelp.proj: Error out if there is more than one zip

.. file when running for Wasm.Build.Tests, or Wasm.Debugger.Tests .

* [wasm] Disable DebuggerTests.ArrayTests on helix

Issue: https://github.com/dotnet/runtime/issues/62661

Using `[Trait..` instead of `ActiveIssue` because: https://github.com/dotnet/runtime/issues/62660

* disable non-wasma builds

* sendtohelixhelp.proj: guard against no payload found

* Disable more tests

* add back builds

* [wasm][debugger] Disable failing debugger test

`DebuggerTests.BreakpointTests.BreakpointInAssemblyUsingTypeFromAnotherAssembly_BothDynamicallyLoaded`

Issue: https://github.com/dotnet/runtime/issues/62823

* Try to fix windows command line

* Move debugger-tests for linux to runtime-staging

* Revert "[wasm][debugger] Fix source-link test (#62786)"

.. as it is breaking debugger tests build on windows.

Issue: https://github.com/dotnet/runtime/issues/62892
This reverts commit 81517407.

* Delete GT_SIMD_CHK and GT_HW_INTRINSIC_CHK

The former was unused, the latter - barely used.
Overall, there is no need for these to be separate
opers, it just leads to unnecessary `#ifdef`s.

* Remove IsArrayBoundsCheck

In loop cloning: redundant with the check for constant lengths below.

In assertion propagation: needless pessimization.

In range check: not needed. While it is not useful to search for the
array lengths from "new int[] { ... }" expressions, it is still useful
to look for assertions related to them.

* GTF_ARR_BOUND_INBND -> GTF_CHK_INDEX_INBND

* Fix formating

* Directory.Delete: prefer DirectoryNotFoundException over UnauthorizedAccess IOException.

* Refactor error handling.

* Remove the VN quirk

* Delete the costing quirk

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>