jashook · sbomer · Jun 27, 2018 · Jun 27, 2018 · Jun 27, 2018 · Jun 27, 2018
diff --git a/BuildToolsVersion.txt b/BuildToolsVersion.txt
@@ -1 +1 @@
-2.2.0-preview1-02829-01
+2.2.0-preview1-03013-03
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -25,6 +25,7 @@ set(VM_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src/vm)
 set(GENERATED_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/src/inc)
 set(GENERATED_EVENTING_DIR ${CMAKE_CURRENT_BINARY_DIR}/eventing)
 set(VERSION_FILE_PATH "${CMAKE_BINARY_DIR}/version.cpp")
+set(PAL_REDEFINES_FILE ${CMAKE_CURRENT_SOURCE_DIR}/src/dlls/mscordac/palredefines.S)
 
 set(CORECLR_SET_RPATH ON)
 if(CORECLR_SET_RPATH)

diff --git a/Documentation/botr/clr-abi.md b/Documentation/botr/clr-abi.md
@@ -603,7 +603,7 @@ JIT32 only generates one epilog (and causes all returns to branch to it) when th
 
 # Synchronized Methods
 
-JIT32/RyuJIT only generates one epilog (and causes all returns to branch to it) when a method is synchronized. See `Compiler::fgAddSyncMethodEnterExit()`. The user code is wrapped in a try/finally. Outside/before the try body, the code initializes a boolean to false. `CORINFO_HELP_MON_ENTER` or `CORINFO_HELP_MON_ENTER_STATIC` are called, passing the lock object (the "this" pointer for instance methods or the Type object for static methods) and the address of the boolean. If the lock is acquired, the boolean is set to true (as an 'atomic' operation in the sense that a Thread.Abort/EH/GC/etc. cannot interrupt the Thread when the boolean does not match the arquired state of the lock). JIT32/RyuJIT follows the exact same logic and arguments for placing the call to `CORINFO_HELP_MON_EXIT` /  `CORINFO_HELP_MON_EXIT_STATIC` in the finally.
+JIT32/RyuJIT only generates one epilog (and causes all returns to branch to it) when a method is synchronized. See `Compiler::fgAddSyncMethodEnterExit()`. The user code is wrapped in a try/finally. Outside/before the try body, the code initializes a boolean to false. `CORINFO_HELP_MON_ENTER` or `CORINFO_HELP_MON_ENTER_STATIC` are called, passing the lock object (the "this" pointer for instance methods or the Type object for static methods) and the address of the boolean. If the lock is acquired, the boolean is set to true (as an 'atomic' operation in the sense that a Thread.Abort/EH/GC/etc. cannot interrupt the Thread when the boolean does not match the acquired state of the lock). JIT32/RyuJIT follows the exact same logic and arguments for placing the call to `CORINFO_HELP_MON_EXIT` /  `CORINFO_HELP_MON_EXIT_STATIC` in the finally.
 
 # Rejit
 

diff --git a/Documentation/botr/dac-notes.md b/Documentation/botr/dac-notes.md
@@ -152,7 +152,7 @@ In addition to pointer types, the DAC must also marshal static and global values
 
 The TADDR and PCODE types we introduced in the example of DAC operation are pure target addresses. These are actually integer types, rather than pointers. This prevents code in the host from incorrectly dereferencing them. The DAC does not treat them as pointers either. Specifically, because we have no type or size information no dereferencing or marshalling can occur. We use these primarily in two situations: when we are treating a target address as pure data and when we need to do pointer arithmetic with target addresses (although we can also do pointer arithmetic with PTR types). Of course, because TADDRs have no type information for the target locations they specify, when we perform address arithmetic, we need to factor in the size explicitly.
 
-We also have one special class of PTRs that don't involve marshaling: PTR\_VOID and PTR\_CVOID. These are the target equivalents of void \* and const void \*, respectively. Because TADDRs are simply numbers, they don't have pointer semantics, which means that if we DACize code by converting void \* to TADDR (as was often the case in the past), we often need extra casts and other changes, even in code that does not compile for the DAC. Using PTR\_VOID makes it easier and cleaner to DACize code that uses void \* by preserving the semantics expected for void \*. If we DACize a function that uses PTR\_VOID or PTR\_CVOID, we can't directly marshal data from these addresses, since we have no idea how much data we would need to read. This means we can't dereference them (or even do pointer aritmetic), but this is identical to the semantics of void \*. As is the case for void \*, we generally cast them to a more specific PTR type when we need to use them. We also have a PTR\_BYTE type, which is a standard marshaled target pointer (that supports pointer arithmetic, etc.). In general, when we DACize code, void \* becomes PTR\_VOID and BYTE \* becomes PTR\_BYTE, just as you would expect. [daccess.h][daccess.h] has explanatory comments that provide more details about the use and semantics of the PTR\_VOID type.
+We also have one special class of PTRs that don't involve marshaling: PTR\_VOID and PTR\_CVOID. These are the target equivalents of void \* and const void \*, respectively. Because TADDRs are simply numbers, they don't have pointer semantics, which means that if we DACize code by converting void \* to TADDR (as was often the case in the past), we often need extra casts and other changes, even in code that does not compile for the DAC. Using PTR\_VOID makes it easier and cleaner to DACize code that uses void \* by preserving the semantics expected for void \*. If we DACize a function that uses PTR\_VOID or PTR\_CVOID, we can't directly marshal data from these addresses, since we have no idea how much data we would need to read. This means we can't dereference them (or even do pointer arithmetic), but this is identical to the semantics of void \*. As is the case for void \*, we generally cast them to a more specific PTR type when we need to use them. We also have a PTR\_BYTE type, which is a standard marshaled target pointer (that supports pointer arithmetic, etc.). In general, when we DACize code, void \* becomes PTR\_VOID and BYTE \* becomes PTR\_BYTE, just as you would expect. [daccess.h][daccess.h] has explanatory comments that provide more details about the use and semantics of the PTR\_VOID type.
 
 Occasionally, legacy code stores a target address in a host pointer type such as void \*. This is always a bug and makes it extremely difficult to reason about the code. It will also break when we support cross-platform, where the pointer types are different sizes). In DAC builds, the void \* type is a host pointer which should never contain a target address. Using PTR\_VOID instead allows us to indicate that a void pointer type is a target address. We are trying to eliminate all such uses, but some are quite pervasive in the code and will take a while to eliminate entirely.
 

diff --git a/Documentation/botr/intro-to-clr.md b/Documentation/botr/intro-to-clr.md
@@ -53,19 +53,17 @@ It is this dedication to ease of use (which goes hand in hand with simplicity of
 
 The runtime has many features, so it is useful to categorize them as follows:
 
-1. Fundamental features – Features that have broad impact on the design of other features.  These include:
-  a. Garbage Collection
-  b. Memory Safety and Type Safety
-  c. High level support for programming languages.
-
-2. Secondary features – Features enabled by the fundamental features that may not be required by many useful programs:
-  a. Program isolation with AppDomains
-  b. Program Security and sandboxing
-
-3. Other Features – Features that all runtime environments need but that do not leverage the fundamental features of the CLR.  Instead, they are the result of the desire to create a complete programming environment.  Among them are:
-  a. Versioning
-  b. Debugging/Profiling
-  c. Interoperation
+1. **Fundamental features** – Features that have broad impact on the design of other features.  These include:
+    1. Garbage Collection
+    2. Memory Safety and Type Safety
+    3. High level support for programming languages.
+2. **Secondary features** – Features enabled by the fundamental features that may not be required by many useful programs:
+    1. Program isolation with AppDomains
+    2. Program Security and sandboxing
+3. **Other Features** – Features that all runtime environments need but that do not leverage the fundamental features of the CLR.  Instead, they are the result of the desire to create a complete programming environment.  Among them are:
+    1. Versioning
+    2. Debugging/Profiling
+    3. Interoperation
 
 ## The CLR Garbage Collector (GC)
 

diff --git a/Documentation/building/crossgen.md b/Documentation/building/crossgen.md
@@ -55,7 +55,7 @@ Using native images
 -------------------
 
 Running CrossGen on an assembly creates a "native image" file, with the extension of `.ni.dll` or `.ni.exe`.
-You should include the native images in your app, either by replacing the original MSIL assmblies with the native images, or by putting the native images next to the MSIL assemblies.
+You should include the native images in your app, either by replacing the original MSIL assemblies with the native images, or by putting the native images next to the MSIL assemblies.
 When the native images are present, CoreCLR runtime will automatically use it instead of the original MSIL assemblies.
 
 Common errors

diff --git a/Documentation/building/linux-instructions.md b/Documentation/building/linux-instructions.md
@@ -38,8 +38,19 @@ In order to get clang-3.9, llvm-3.9 and lldb-3.9 on Ubuntu 14.04, we need to add
     ~$ wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add -
     ~$ sudo apt-get update
 
-Note: arm clang has a known issue with CompareExchange (#15074), so for arm you have to use clang-4.0 or higher, the official build uses clang-5.0.
-
+Note: ARM clang has a known issue with CompareExchange
+([#15074](https://github.com/dotnet/coreclr/issues/15074)), so for ARM you must
+use clang-4.0 or higher.  Moreover, when building with clang-5.0, the
+following errors occur:
+
+```
+coreclr/src/debug/inc/arm/primitives.h:66:1: error: __declspec attribute 'selectany' is
+      not supported [-Werror,-Wignored-attributes]
+```
+
+This is fixed in clang-5.0.2, which can be installed from the apt
+repository listed below.
+
 For other version of Debian/Ubuntu, please visit http://apt.llvm.org/.
 
 Then install the packages you need:
@@ -98,9 +109,32 @@ After the build is complete you will be able to find the output in the `bin` fol
 Build for ARM/Linux
 ===================
 
-Libunwind-arm requires fixes that are not included in Ubuntu 14.04, yet. The fix allows libunwind-arm not to break when it is ordered to access unaccessible memory locations.
+The CI system and official builds use Docker to build ARM for Linux (for example, see the latest build [here](https://ci.dot.net/job/dotnet_coreclr/job/master/job/arm_cross_checked_ubuntu/lastSuccessfulBuild/consoleText)). The Docker container has pre-built rootfs directories containing the required tools. To build this way, do the following:
+
+* Install Docker, probably Community Edition, on Windows, Mac, or Linux, from https://www.docker.com/. Some useful post-install setup is:
+  * Linux: add your user to the docker group, this will avoid running docker with `sudo`:
+
+    `sudo usermod -a <your account name> -G docker`
+
+  * Windows: switch to Linux containers. This can be done by right clicking on the Docker icon in the lower right corner and clicking "Switch to Linux containers".
+* Build using the Docker container (this is a `bash` script, for simplicity):
+
+```
+ROOT=/Users/me/git/coreclr
+DOCKER_ARGS="run -i --rm -v ${ROOT}:/mnt/coreclr -w /mnt/coreclr -e ROOTFS_DIR=/crossrootfs/arm -e CAC_ROOTFS_DIR=/crossrootfs/x86 microsoft/dotnet-buildtools-prereqs:ubuntu-14.04-cross-e435274-20180426002420"
+docker ${DOCKER_ARGS} /mnt/coreclr/build.sh arm checked cross crosscomponent
+docker ${DOCKER_ARGS} /mnt/coreclr/build-test.sh arm checked cross generatelayoutonly
+```
+
+Make sure you update the `ROOT` environment to point to your git clone of the coreclr repo.
+
+The current Docker tag being used by the CI can be found in the `getDockerImageName` function in the [netci.groovy](https://github.com/dotnet/coreclr/blob/master/netci.groovy) file.
+
+Libunwind issue
+---------------
+ARM libunwind versions before 1.3 require a fix. The fix allows libunwind not to break when it is ordered to access unaccessible memory locations. See [this](https://github.com/dotnet/coreclr/pull/3923) issue for history.
 
-First, import the patch from the libunwind upstream: http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commit;h=770152268807e460184b4152e23aba9c86601090
+If required, first import the patch from the libunwind upstream: http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commit;h=770152268807e460184b4152e23aba9c86601090.
 
 Then, expand the coverage of the upstream patch by:
 
@@ -124,7 +158,7 @@ index 1ed3dbf..c643032 100644
 ```
 
 Additional optimization levels for ARM/Linux: -Oz and -Ofast
-============================================================
+------------------------------------------------------------
 
 This instruction is to enable additional optimization levels such as -Oz and -Ofast on ARM/Linux. The below table shows what we have to enable for the code optimization of the CoreCLR run-time either the size or speed on embedded devices. 
 

diff --git a/Documentation/building/test-configuration.md b/Documentation/building/test-configuration.md
@@ -1,41 +1,54 @@
-## General Test Infrastructure Notes ##
+# General Test Infrastructure
 
-### Kinds of Build Properties ###
-* Build Only
-> `<CLRTestKind>BuildOnly</CLRTestKind>`
-
- * Builds an executable. 
- * Will not execute it. 
+## Test "Kind"
 
+* Build Only
+  * Builds an executable.
+  * Will not execute.
+  * e.g. `<CLRTestKind>BuildOnly</CLRTestKind>`
 * Run Only
-> `<CLRTestKind>RunOnly</CLRTestKind>`
+  * Can use output of `BuildOnly` or `BuildAndRun` projects with different command line arguments.
+  * e.g. `<CLRTestKind>RunOnly</CLRTestKind>`
+* Build And Run
+  * Builds an executable.
+  * Will execute said executable.
+  * e.g. `<CLRTestKind>BuildAndRun</CLRTestKind>`
+* Shared Libraries
+  * For building libraries common to zero or more tests.
+  * e.g. `<CLRTestKind>SharedLibrary</CLRTestKind>`
 
- * Can use Ouput of Build and Run Project with different command line arguments. 
-* Build and Run
-> `<CLRTestKind>BuildAndRun</CLRTestKind>`
+By default (i.e. if not specified explicitly), test "Kind" is `BuildAndRun`.
 
- * Builds an executable.
- * Will execute said executable. 
-* Shared Libraries
-> `<CLRTestKind>SharedLibrary</CLRTestKind>`
+## Priority
+
+Test cases are categorized by priority level. The most important subset should be and is the smallest subset. This subset is called priority 0.
 
- * For building libraries common to zero or more tests. 
+* By default, a test case is priority 0. Tests must be explicitly de-prioritized.
+* Set the priority of a test by setting the property `<CLRTestPriority>` in the test's project file.
+  * e.g. `<CLRTestPriority>2</CLRTestPriority>`
+* Lower priority values are always run in conjunction when running higher priority value tests.
+  * i.e. if a developer elects to do a priority 2 test run, then all priority 0, 1 and 2 tests are run.
 
+## Adding Test Guidelines
 
-By default (i.e. if not specified explicitly) a project file is BuildAndRun.
+* All test source files should include the following banner:
+```
+    // Licensed to the .NET Foundation under one or more agreements.
+    // The .NET Foundation licenses this file to you under the MIT license.
+    // See the LICENSE file in the project root for more information.
+```
+* Disable building of a test by conditionally setting the `<DisableProjectBuild>` property.
+	* e.g. `<DisableProjectBuild Condition=" '$(Platform)' == 'arm64' ">true</DisableProjectBuild>`
+* Add NuGet/MyGet references by updating the following [project file](https://github.com/dotnet/coreclr/blob/master/tests/src/Common/test_dependencies/test_dependencies.csproj).
+* Build against the `mscorlib` facade by adding `<ReferenceLocalMscorlib>true</ReferenceLocalMscorlib>` to the test project.
 
-### Priority ###
-Testcases are categorized by their priority levels. The most important subset should be and is the smallest subset. This subset is called priority 0.
- * By default, a testcase is priority 0. You must elect to de-prioritize a test.
-  * To de-prioritize a test, add a property _CLRTestPriority_ to the test's project file.
-> `<CLRTestPriority>2</CLRTestPriority>`
- * Lower priority values are always run in conjunction when running higher priority value tests. I.e. if a developer elects to do a priority 2 test run, then all priority 0, 1 and 2 tests are run.
+### Creating a new C# test project
 
-### Adding Tests ###
-#### Converting an existing C# project ####
-  * Remove AssemblyName
-  * Swap in dir.props
-  * Swap in dir.targets
-  * Assign a CLRTestKind
-  * (optional) Assign a priority value
+**TODO**
 
+### Converting an existing C# project
+  * Remove the `<AssemblyName>` property
+  * Import `dir.props`
+  * Import `dir.targets`
+  * Assign a `<CLRTestKind>`
+  * (optional) Assign a priority value
-Original file line number
+Diff line change
@@ Expand Up @@
     # Synchronized Methods
-    JIT32/RyuJIT only generates one epilog (and causes all returns to branch to it) when a method is synchronized. See `Compiler::fgAddSyncMethodEnterExit()`. The user code is wrapped in a try/finally. Outside/before the try body, the code initializes a boolean to false. `CORINFO_HELP_MON_ENTER` or `CORINFO_HELP_MON_ENTER_STATIC` are called, passing the lock object (the "this" pointer for instance methods or the Type object for static methods) and the address of the boolean. If the lock is acquired, the boolean is set to true (as an 'atomic' operation in the sense that a Thread.Abort/EH/GC/etc. cannot interrupt the Thread when the boolean does not match the arquired state of the lock). JIT32/RyuJIT follows the exact same logic and arguments for placing the call to `CORINFO_HELP_MON_EXIT` /  `CORINFO_HELP_MON_EXIT_STATIC` in the finally.
+    JIT32/RyuJIT only generates one epilog (and causes all returns to branch to it) when a method is synchronized. See `Compiler::fgAddSyncMethodEnterExit()`. The user code is wrapped in a try/finally. Outside/before the try body, the code initializes a boolean to false. `CORINFO_HELP_MON_ENTER` or `CORINFO_HELP_MON_ENTER_STATIC` are called, passing the lock object (the "this" pointer for instance methods or the Type object for static methods) and the address of the boolean. If the lock is acquired, the boolean is set to true (as an 'atomic' operation in the sense that a Thread.Abort/EH/GC/etc. cannot interrupt the Thread when the boolean does not match the acquired state of the lock). JIT32/RyuJIT follows the exact same logic and arguments for placing the call to `CORINFO_HELP_MON_EXIT` /  `CORINFO_HELP_MON_EXIT_STATIC` in the finally.
     # Rejit
@@ Expand Down @@