Merge remote-tracking branch 'origin/main' into thays_componentize_de…

…bugger2

* origin/main: (107 commits)
  Disable MacCatalyst arm64 PR test runs on staging pipeline (dotnet#54678)
  [WASM] Fix async/await in config loading (dotnet#54652)
  Fix for heap_use_after_free flagged by sanitizer (dotnet#54679)
  [wasm] Bump emscripten to 2.0.23 (dotnet#53603)
  Fix compiler references when building inside VS (dotnet#54614)
  process more TLS frames at one when available (dotnet#50815)
  Add PeriodicTimer (dotnet#53899)
  UdpClient with span support (dotnet#53429)
  exclude fragile tests (dotnet#54671)
  get last error before calling a method that might fail as well (dotnet#54667)
  [FileStream] add tests for device and UNC paths (dotnet#54545)
  Fix sporadic double fd close (dotnet#54660)
  Remove Version.Clone from AssemblyName.Clone (dotnet#54621)
  [wasm] Enable fixed libraries tests (dotnet#54641)
  [wasm] Fix blazor/aot builds (dotnet#54651)
  [mono][wasm] Fix compilation error on wasm (dotnet#54659)
  Fix telemetry for Socket connects to Dns endpoints (dotnet#54071)
  [wasm] Build static components; include hot_reload in runtime (dotnet#54568)
  [wasm][debugger] Reuse debugger-agent on wasm debugger (dotnet#52300)
  Put Crossgen2 in sync with dotnet#54235 (dotnet#54438)
  ...

Directory.Build.props

@@ -83,6 +83,7 @@
     <WasmBuildTasksAssemblyPath>$([MSBuild]::NormalizePath('$(WasmBuildTasksDir)', 'WasmBuildTasks.dll'))</WasmBuildTasksAssemblyPath>
     <MonoAOTCompilerTasksAssemblyPath>$([MSBuild]::NormalizePath('$(MonoAOTCompilerDir)', 'MonoAOTCompiler.dll'))</MonoAOTCompilerTasksAssemblyPath>
     <RuntimeConfigParserTasksAssemblyPath>$([MSBuild]::NormalizePath('$(RuntimeConfigParserDir)', 'RuntimeConfigParser.dll'))</RuntimeConfigParserTasksAssemblyPath>
+    <ILAsmToolPath Condition="'$(DotNetBuildFromSource)' == 'true'">$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'coreclr', '$(TargetOS).$(TargetArchitecture).$(Configuration)'))</ILAsmToolPath>
   </PropertyGroup>
 
   <PropertyGroup Label="CalculateConfiguration">
@@ -202,6 +203,17 @@
     <TargetsUnix Condition="'$(TargetsFreeBSD)' == 'true' or '$(Targetsillumos)' == 'true' or '$(TargetsSolaris)' == 'true' or '$(TargetsLinux)' == 'true' or '$(TargetsNetBSD)' == 'true' or '$(TargetsOSX)' == 'true' or '$(TargetsMacCatalyst)' == 'true' or '$(TargetstvOS)' == 'true' or '$(TargetsiOS)' == 'true' or '$(TargetsAndroid)' == 'true'">true</TargetsUnix>
   </PropertyGroup>
 
+  <PropertyGroup>
+    <MicrosoftNetCoreAppRefPackDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'microsoft.netcore.app.ref'))</MicrosoftNetCoreAppRefPackDir>
+    <MicrosoftNetCoreAppRefPackRefDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRefPackDir)', 'ref', '$(NetCoreAppCurrent)'))</MicrosoftNetCoreAppRefPackRefDir>
+    <MicrosoftNetCoreAppRefPackDataDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRefPackDir)', 'data'))</MicrosoftNetCoreAppRefPackDataDir>
+
+    <MicrosoftNetCoreAppRuntimePackDir>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'microsoft.netcore.app.runtime.$(PackageRID)', '$(Configuration)'))</MicrosoftNetCoreAppRuntimePackDir>
+    <MicrosoftNetCoreAppRuntimePackRidDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackDir)', 'runtimes', '$(PackageRID)'))</MicrosoftNetCoreAppRuntimePackRidDir>
+    <MicrosoftNetCoreAppRuntimePackRidLibTfmDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'lib', '$(NetCoreAppCurrent)'))</MicrosoftNetCoreAppRuntimePackRidLibTfmDir>
+    <MicrosoftNetCoreAppRuntimePackNativeDir>$([MSBuild]::NormalizeDirectory('$(MicrosoftNetCoreAppRuntimePackRidDir)', 'native'))</MicrosoftNetCoreAppRuntimePackNativeDir>
+  </PropertyGroup>
+
   <!--Feature switches -->
   <PropertyGroup>
     <EnableNgenOptimization Condition="'$(EnableNgenOptimization)' == '' and ('$(Configuration)' == 'Release' or '$(Configuration)' == 'Checked')">true</EnableNgenOptimization>

THIRD-PARTY-NOTICES.TXT

@@ -680,7 +680,7 @@ worldwide. This software is distributed without any warranty.
 
 See <http://creativecommons.org/publicdomain/zero/1.0/>.
 
-License for fastmod (https://github.com/lemire/fastmod)
+License for fastmod (https://github.com/lemire/fastmod) and ibm-fpgen (https://github.com/nigeltao/parse-number-fxx-test-data)
 --------------------------------------
 
    Copyright 2018 Daniel Lemire
@@ -952,3 +952,29 @@ by constants, including codegen instructions. The unsigned division incorporates
 "round down" optimization per ridiculous_fish.
 
 This is free and unencumbered software. Any copyright is dedicated to the Public Domain.
+
+
+License notice for mimalloc
+-----------------------------------
+
+MIT License
+
+Copyright (c) 2019 Microsoft Corporation, Daan Leijen
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

docs/design/coreclr/botr/type-loader.md

@@ -76,21 +76,25 @@ There is a relatively small number of entry-points to the loader. Although the s
 
 There are usually many calls to the type loader during JITting. Consider:
 
-	object CreateClass()
-	{
-	    return new MyClass();
-	}
+```csharp
+object CreateClass()
+{
+    return new MyClass();
+}
+```
 
 In the IL, MyClass is referred to using a metadata token. In order to generate a call to the `JIT_New` helper which takes care of the actual instantiation, the JIT will ask the type loader to load the type and return a handle to it. This handle will be then directly embedded in the JITted code as an immediate value. The fact that types and members are usually resolved and loaded at JIT time and not at run-time also explains the sometimes confusing behavior easily hit with code like this:
 
-	object CreateClass()
-	{
-	    try {
-	        return new MyClass();
-	    } catch (TypeLoadException) {
-	        return null;
-	    }
-	}
+```csharp
+object CreateClass()
+{
+    try {
+        return new MyClass();
+    } catch (TypeLoadException) {
+        return null;
+    }
+}
+```
 
 If `MyClass` fails to load, for example because it's supposed to be defined in another assembly and it was accidentally removed in the newest build, then this code will still throw `TypeLoadException`. The reason that the catch block did not catch it is that it never ran! The exception occurred during JITting and would only be catchable in the method that called `CreateClass` and caused it to be JITted. In addition, it may not be always obvious at which point the JITting is triggered due to inlining, so users should not expect and rely on deterministic behavior.
 
@@ -153,14 +157,16 @@ both the same type.
 
 When the type loader is asked to load a specified type, identified for example by a typedef/typeref/typespec **token** and a **Module** , it does not do all the work atomically at once. The loading is done in phases instead. The reason for this is that the type usually depends on other types and requiring it to be fully loaded before it can be referred to by other types would result in infinite recursion and deadlocks. Consider:
 
-	class A<T> : C<B<T>>
-	{ }
+```csharp
+class A<T> : C<B<T>>
+{ }
 
-	class B<T> : C<A<T>>
-	{ }
+class B<T> : C<A<T>>
+{ }
 
-	class C<T>
-	{ }
+class C<T>
+{ }
+```
 
 These are valid types and apparently `A` depends on `B` and `B` depends on `A`.
 
@@ -195,10 +201,12 @@ A placeholder to be substituted by another type; the `T` in the declaration of `
 
 A type being substituted for a generic parameter; the `int` in `List<int>`. Note that a generic parameter can also be used as an argument. Consider:
 
-	List<T> GetList<T>()
-	{
-	    return new List<T>();
-	}
+```csharp
+List<T> GetList<T>()
+{
+    return new List<T>();
+}
+```
 
 The method has one generic parameter `T` which is used as a generic argument for the generic list class.
 
@@ -209,28 +217,38 @@ An optional requirement placed by generic parameters on its potential generic ar
 1. Special constraints
   - Reference type constraint - the generic argument must be a reference type (as opposed to a value type). The `class` keyword is used in C# to express this constraint.
 
-			public class A<T> where T : class
+    ```csharp
+    public class A<T> where T : class
+    ```
 
   - Value type constraint - the generic argument must be a value type different from `System.Nullable<T>`. C# uses the `struct` keyword.
 
-			public class A<T> where T : struct
+    ```csharp
+    public class A<T> where T : struct
+    ```
 
   - Default constructor constraint - the generic argument must have a public parameterless constructor. This is expressed by `new()` in C#.
 
-			public class A<T> where T : new()
+    ```csharp
+    public class A<T> where T : new()
+    ```
 
 2. Base type constraints - the generic argument must be derived from
 (or directly be of) the given non-interface type. It obviously makes
 sense to use only zero or one reference type as a base types
 constraint.
 
-		public class A<T> where T : EventArgs
+    ```csharp
+    public class A<T> where T : EventArgs
+    ```
 
 3. Implemented interface constraints - the generic argument must
 implement (or directly be of) the given interface type.  Zero or more
 interfaces can be given.
 
-		public class A<T> where T : ICloneable, IComparable<T>
+    ```csharp
+    public class A<T> where T : ICloneable, IComparable<T>
+    ```
 
 The above constraints are combined with an implicit AND, i.e. a
 generic parameter can be constrained to be derived from a given type,
@@ -239,11 +257,13 @@ generic parameters of the declaring type can be used to express the
 constraints, introducing interdependencies among the parameters. For
 example:
 
-	public class A<S, T, U>
-		where S : T
-		where T : IList<U> {
-	    void f<V>(V v) where V : S {}
-	}
+```csharp
+public class A<S, T, U>
+	where S : T
+	where T : IList<U> {
+    void f<V>(V v) where V : S {}
+}
+```
 
 **Instantiation**
 
@@ -259,7 +279,9 @@ declared. There exists exactly one typical instantiation for each
 generic type and method. Usually when one talks about an open generic
 type, they have the typical instantiation in mind. Example:
 
-	public class A<S, T, U> {}
+```csharp
+public class A<S, T, U> {}
+```
 
 The C# `typeof(A<,,>)` compiles to ldtoken A\'3 which makes the
 runtime load ``A`3`` instantiated at `S` , `T` , `U`.

docs/design/features/cross-dac.md

@@ -0,0 +1,97 @@
+# Cross DAC Notes
+
+The `crossdac` is a cross-compiled DAC. It is compiled to execute on one platform, but debug a target of a different architecture.
+
+Our current crossdacs are all:
+
+- compiled to run on Windows
+- Same bitness. (Target and host have the same number of bits.
+- target a *nix variant
+
+The crossdac allow us to use Windows debugging tools to debug dumps from *nix processes.
+
+## Design
+
+### Limitations
+
+- To avoid solving remoting and synchronization issues, the crossdac will not support live processes. Only dump debugging is supported.
+- Similar to the DAC, each cross DAC must match its runtime. The DACs are indexed on a symbol server to allow the debuggers to get these as needed.
+
+### Conditional Code Selection
+
+This is a simple cross compilation of the DAC, `C++` code. This mean the `HOST_*` and the `TARGET_*` are configured differently. In this context:
+
+- `HOST` refers to the architecture of the platform that is running the debugger.
+- `TARGET` refers to the platform that generated the code dump.
+
+In general, most code should be conditioned on `TARGET_*` variables. This is because in general we want the `DAC` to behave identically when cross compiled.
+
+Code must be conditioned on `HOST` when it refers to host needed services. These have typically been thing like file i/o and memory allocation.
+
+Initial implementation allowed the compiler to find most of these. The strategy was to assume all code should be conditioned on `TARGET` and let the compiler gripe.
+
+### Type Layout
+
+The DAC is essentially a memory parsing tool with supporting functionality. The layout of types in the DAC must match the layout of types in the runtime.
+
+The `C++` standard is not explicit about all layout rules of data structures. Due to its historical evolution from `C`, most structures are arranged in an intuitive easily understood fashion. Newer and more exotic structures are less consistent.
+
+Experimentation has shown that layout varies in inheritance cases. The DAC does not support general multiple inheritance, so that simplifies things. It does support multiple inheritance with the empty base classes.
+
+These cases have proven to be problematic:
+
+- Classes with empty base classes. (I the only issue is with multiple base classes.)
+  - By default `gcc` use an empty base class optimization to eliminate the 1 byte of space these empty base classes normally consume (alone).
+  - By default `Windows` compilers do not do this optimization. This is to preserve backward binary compatibility.
+  - The Windows compilers allow this optimization to be enabled. Our code uses `EMPTY_BASES_DECL` to enable this optimization. It has to be applied to every structure that has multiple base classes or derives from a such a structure. See `__declspec(empty_bases)`.
+- Packing of the first member of the derived class. In the case where the base class ended with padding:
+  - `gcc` compilers reuse the padding for the first member of the derived class. This effectively removes the padding of the base class in the derived class.
+  - Windows compilers do not remove this padding.
+  - Our code uses the `DAC_ALIGNAS(a)` macro before the first element of the derived class to force the `gcc` compiler to align that member and keep the base classes padding.
+    - The `a` parameter is preferentially the base classes typename.
+    - However, in some cases the compiler will not allow this due to some circular layout issues it causes. In these cases, `a` can refer to a well known type instead. I prefer `int64_t`, `int32_t`, `size_t` ...
+
+#### DacCompareNativeTypes Usage
+
+I wrote and used [DacCompareNativeTypes](https://github.com/dotnet/diagnostics/tree/main/src/tests/DacCompareNativeTypes), to locate and identify type layout issues.
+
+The tool is a bit crude, but it helped get the job done.
+
+The `libcoreclr.so` has a lot of symbols. This proved very slow. So to expedite things, I compared the `dac` and later the `dbi` libraries for structure layout. This had the advantage of eliminating irrelevant data structures.
+
+The compilers generate different debug data and different hidden data structures. The tool tries to overlook these. Be aware that not all differences are real. Some data structures are host only so these are expected to be different.
+
+I usually ran the tool in a debugger so that I could look at other available meta-data the tool keeps. i.e. source file and line number.
+
+### Missing/Different types
+
+There are some cases where types are defined by the Target. These types maybe missing or different on the Host. In these cases we define the cross compilation types in `src/coreclr/inc/crosscomp.h`.
+
+See `T_CRITICAL_SECTION` for a key example. In this case both host and target supported critical sections, but we needed to correctly map the target data structures. So we needed a type defined which was the TARGET's `CRITICAL_SECTION`.
+
+So the Target's definition was made available for the cross compile. Additionally the macro was created to make sure references which required the Target's definition could be separated from ones which might need the host's definition.
+
+There is also some defensive programming to make sure these structures accurate. See `T_CRITICAL_SECTION_VALIDATION_MESSAGE` for one example.
+
+### Out of Process Unwinding
+
+To fully support native stack processing, we needed a Target unwinder. For this `libunwind` was also cross-compiled.
+
+See [CMake cross libunwind](https://github.com/dotnet/runtime/blob/0049c629381c5a18e4dadd1038c2bd6b3ae6e3e6/src/coreclr/CMakeLists.txt#L113)
+
+### DBI
+
+I use the term `DAC` in this document to refer to both the `DAC` and the `DBI` debug interface. Both were actually cross compiled. Be aware.
+
+### Build entry point
+
+The main build systme change is adding the ability to set the Target OS on a Windows build.
+
+- See [build-runtime.cmd changes](https://github.com/dotnet/runtime/blob/0049c629381c5a18e4dadd1038c2bd6b3ae6e3e6/src/coreclr/build-runtime.cmd#L133-L134)
+- See [Subsets.props](https://github.com/dotnet/runtime/blob/0049c629381c5a18e4dadd1038c2bd6b3ae6e3e6/eng/Subsets.props#L191-L197)
+
+There are also changes to the official build to set these flags package the results and upload to the symbol server.
+
+### Client changes
+
+Various changes were required in the DAC clients to consume the new crossdac. These are really out of the scope of this document.

docs/project/list-of-diagnostics.md

@@ -80,6 +80,7 @@ The PR that reveals the implementation of the `<IncludeInternalObsoleteAttribute
 |  __`SYSLIB0023`__ | RNGCryptoServiceProvider is obsolete. To generate a random number, use one of the RandomNumberGenerator static methods instead. |
 |  __`SYSLIB0024`__ | Creating and unloading AppDomains is not supported and throws an exception. |
 |  __`SYSLIB0025`__ | SuppressIldasmAttribute has no effect in .NET 6.0+. |
+|  __`SYSLIB0026`__ | X509Certificate and X509Certificate2 are immutable. Use the appropriate constructor to create a new certificate. |
 
 ## Analyzer Warnings
 

docs/workflow/building/libraries/webassembly-instructions.md

@@ -7,7 +7,7 @@ If you haven't already done so, please read [this document](../../README.md#Buil
 The **correct version** of Emscripten SDK (emsdk) needs to be installed.
 * Run `make -C src/mono/wasm provision-wasm` to install emsdk into `src/mono/wasm/emsdk`.
 * Alternatively follow the [installation guide](https://emscripten.org/docs/getting_started/downloads.html#sdk-download-and-install).
-Do not install `latest` but rather specific version e.g. `./emsdk install 2.0.21`. See [emscripten-version.txt](..\..\..\..\src\mono\wasm\emscripten-version.txt)
+Do not install `latest` but rather specific version e.g. `./emsdk install 2.0.23`. See [emscripten-version.txt](..\..\..\..\src\mono\wasm\emscripten-version.txt)
 
 Once installed the `EMSDK_PATH` environment variable needs to be set:
 

docs/workflow/requirements/windows-requirements.md

@@ -34,7 +34,7 @@ Visual Studio 2019 installation process:
 
 A `.vsconfig` file is included in the root of the dotnet/runtime repository that includes all components needed to build the dotnet/runtime repository. You can [import `.vsconfig` in your Visual Studio installer](https://docs.microsoft.com/en-us/visualstudio/install/import-export-installation-configurations?view=vs-2019#import-a-configuration) to install all necessary components.
 
-The dotnet/runtime repository requires at least Visual Studio 2019 16.6.
+Visual Studio 2019 16.6 or later is required for building the repository. Visual Studio 2019 16.10 is required to work with the libraries projects inside the Visual Studio IDE.
 
 ## CMake