Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/corert.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarek Safar <marek.safar@gmail.com>2018-09-19 15:19:22 +0300
committerGitHub <noreply@github.com>2018-09-19 15:19:22 +0300
commitefd29b5cf854679349066e22ef9038b8cfe76d94 (patch)
tree2de750c1ac8a487d7f6d149592a6362ade6a5a77 /Documentation
parentf9124d69e41d42196510dd7234b2d53fed48ad4c (diff)
parent49f9ed0e66fc2d4cd682821396c6af5e80182048 (diff)
Merge pull request #25 from ntherning/bump-corert
Bump to latest upstream
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/cross-building.md100
-rw-r--r--Documentation/how-to-build-ObjectWriter.md10
-rw-r--r--Documentation/how-to-build-WebAssembly.md4
-rw-r--r--Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md10
-rw-r--r--Documentation/how-to-build-and-run-ilcompiler-in-vscode.md2
-rw-r--r--Documentation/how-to-run-tests.md85
-rw-r--r--Documentation/intro-to-corert.md14
-rw-r--r--Documentation/prerequisites-for-building.md4
8 files changed, 181 insertions, 48 deletions
diff --git a/Documentation/cross-building.md b/Documentation/cross-building.md
index c95fd15dd..291a92df7 100644
--- a/Documentation/cross-building.md
+++ b/Documentation/cross-building.md
@@ -52,54 +52,104 @@ As usual the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.
Using CoreRT for cross compiling under arm on x86 host
-----------------------
-It is possible to use CoreRT for compiling under arm/armel on x86 host (or on x64 machine using roots).
+It's possible to use CoreRT for compiling under arm/armel on x86 host (or on x64 machine using rootfs).
+You can build Debug or Release version.
+For example Release means: release CoreRT/CoreCLR/CoreFX builds + CoreRT(ILC) release enabled optimizations.
+For better components compatibility, if you want to build Debug version, you must compile ALL projects as Debug version.
+Otherwise, ALL as Release version.
-1. Build CoreCLR for x86 (`checked` version)
+1. Build CoreCLR for x86
```
sudo ./cross/build-rootfs.sh x86 xenial
-./build.sh clang3.9 x86 checked verbose cross skiptests
+./build.sh x86 debug verbose cross
```
-
-2. Build CoreFX (`Debug` version)
-3. Build CoreRT for armel, x64, x86
+2. Build CoreFX
+```
+sudo ./cross/build-rootfs.sh x86 xenial
+./build-native.sh -debug -buildArch=x86 -- verbose cross
+./build-managed.sh -debug -verbose
+```
+3. Build CoreRT for x86 and armel
```
-sudo ./cross/build-rootfs.sh armel tizen cross
-./build.sh clang3.9 armel debug verbose cross
-./build.sh debug verbose skiptests
-./build.sh clang3.9 x86 debug verbose cross skiptests
+sudo ./cross/build-rootfs.sh armel tizen
+sudo ./cross/build-rootfs.sh x86 xenial
+./build.sh armel debug verbose cross
+./build.sh x86 debug verbose cross crosstarget skiptests
```
-4. Copy necessary binaries to working directory (in x86 rootfs)
+4. Copy necessary binaries to working directory in x86 rootfs.
+Or in any host directory, if you have 32-bit multiarch-support on your x64 host.
```
-cp ${CORECLR}/bin/Product/Linux.x86.Checked ${WORKING_DIR}
-cp ${CORERT}/bin/Linux.x86.Debug/tools/ilc.dll ${WORKING_DIR}
-cp ${CORERT}/bin/Linux.x86.Debug/tools/ILCompiler.* ${WORKING_DIR}
-cp ${CORERT}/bin/Linux.x86.Debug/tools/System.CommandLine.dll ${WORKING_DIR}
-cp ${CORERT}/bin/Linux.x86.Debug/tools/Microsoft.DiaSymReader.dll ${WORKING_DIR}
-cp ${CORERT}/bin/Linux.x86.Debug/tools/jitinterface.so ${WORKING_DIR}
-cp -r ${CORERT}/bin/Linux.x86.Debug/framework ${WORKING_DIR}
-
-# Copy CoreRT sdk binaries from target (armel) output folder
+# 1) Copy CoreCLR(with CoreRun) part
+cp ${CORECLR}/bin/Product/Linux.x86.Debug/* ${WORKING_DIR}
+
+# 2) Copy CoreRT part
+cp ${CORERT}/bin/Linux.armel.Debug/tools/ilc.dll ${WORKING_DIR}
+cp ${CORERT}/bin/Linux.armel.Debug/tools/ILCompiler.* ${WORKING_DIR}
+cp ${CORERT}/bin/Linux.armel.Debug/tools/System.CommandLine.dll ${WORKING_DIR}
+cp ${CORERT}/bin/Linux.armel.Debug/tools/Microsoft.DiaSymReader.dll ${WORKING_DIR}
+cp -r ${CORERT}/bin/Linux.armel.Debug/framework ${WORKING_DIR}
cp -r ${CORERT}/bin/Linux.armel.Debug/sdk ${WORKING_DIR}
+
+# 3) Copy CoreRT x86 jitinterface with target armel version
+cp ${CORERT}/bin/Linux.x86.Debug/tools/armeljitinterface.so ${WORKING_DIR}/jitinterface.so
+
+# 4) Copy CoreFX part
+# Copy native architecture dependence libs
+cp ${COREFX}/bin/Linux.x86.Debug/native/* ${WORKING_DIR}
+# Copy arch independence libs
+# This part varies depending on the application, these dependencies for HelloWorld only
+NETCORE_PATH=netcoreapp-Linux-Debug-x64
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.Extensions.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Collections.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Reflection.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Reflection.Metadata.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Collections.Immutable.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Console.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.IO.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.InteropServices.RuntimeInformation.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.InteropServices.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Threading.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Diagnostics.Debug.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Linq.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.IO.FileSystem.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.IO.MemoryMappedFiles.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.IO.UnmanagedMemoryStream.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.IO.FileSystem.Primitives.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.Handles.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Text.Encoding.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Text.Encoding.Extensions.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Reflection.Primitives.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Collections.Concurrent.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Security.Cryptography.Algorithms.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Security.Cryptography.Primitives.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Runtime.CompilerServices.Unsafe.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Globalization.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Private.Xml.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Diagnostics.Tracing.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Buffers.dll ${WORKING_DIR}
+cp ${COREFX}/bin/runtime/${NETCORE_PATH}/System.Memory.dll ${WORKING_DIR}
```
5. Rename RyuJIT compiler library
```
# Use cross-compiler library as default for ILC
+# libclrjit.so is used by the CoreCLR that compiler runs on,
+# and libclrjitilc.so is used for the actual compilation.
cp ${WORKING_DIR}/libarmelnonjit.so ${WORKING_DIR}/libclrjitilc.so
-
-# ... or ARM version instead if it's needed
-# cp ${WORKING_DIR}/libprotojit.so ${WORKING_DIR}/libclrjitilc.so
```
6. [Build ObjectWriter library](how-to-build-ObjectWriter.md). You have to compile it on x86 chroot.
7. And to execute use:
```
+# Hello.ilc.rsp is in CoreRT armel build. It's necessary to edit the paths on the relatively our working directory.
./corerun ilc.dll --codegenopt "AltJitNgen=*" --verbose @Hello.ilc.rsp
+
# Any other options to RyuJIT could be passed via --codegenopt argument, e.g.:
-#./corerun ilc.dll --codegenopt "AltJitNgen=*" --codegenopt "NgenDisasm=*" --verbose @Hello.ilc.rsp
+# ./corerun ilc.dll --codegenopt "AltJitNgen=*" --codegenopt "NgenDisasm=*" --verbose @Hello.ilc.rsp
# For linking
-clang-3.9 -target arm-linux-gnueabi --sysroot=corert/cross/rootfs/armel -Bcorert/cross/rootfs/armel/usr/lib/gcc/armv7l-tizen-linux-gnueabi/6.2.1 -Lcorert/cross/rootfs/armel/usr/lib/gcc/armv7l-tizen-linux-gnueabi/6.2.1 Hello.o -o Hello corert/bin/Linux.armel.Debug/sdk/libbootstrapper.a corert/bin/Linux.armel.Debug/sdk/libRuntime.a corert/bin/Linux.armel.Debug/sdk/libSystem.Private.CoreLib.Native.a corert/bin/Linux.armel.Debug/framework/System.Native.a corert/bin/Linux.armel.Debug/framework/libSystem.Globalization.Native.a -g -Wl,-rpath,'$ORIGIN' -pthread -lstdc++ -ldl -lm -luuid -lrt -fPIC
+clang -target arm-linux-gnueabi --sysroot=corert/cross/rootfs/armel -Bcorert/cross/rootfs/armel/usr/lib/gcc/armv7l-tizen-linux-gnueabi/6.2.1 -Lcorert/cross/rootfs/armel/usr/lib/gcc/armv7l-tizen-linux-gnueabi/6.2.1 Hello.o -o Hello corert/bin/Linux.armel.Debug/sdk/libbootstrapper.a corert/bin/Linux.armel.Debug/sdk/libRuntime.a corert/bin/Linux.armel.Debug/sdk/libSystem.Private.CoreLib.Native.a corert/bin/Linux.armel.Debug/framework/System.Native.a corert/bin/Linux.armel.Debug/framework/System.Globalization.Native.a -g -Wl,-rpath,'$ORIGIN' -pthread -lstdc++ -ldl -lm -luuid -lrt -fPIC
```
diff --git a/Documentation/how-to-build-ObjectWriter.md b/Documentation/how-to-build-ObjectWriter.md
index 3f20e177c..8999a4403 100644
--- a/Documentation/how-to-build-ObjectWriter.md
+++ b/Documentation/how-to-build-ObjectWriter.md
@@ -3,6 +3,14 @@
ObjWriter is based on LLVM, so it requires recent CMake and GCC/Clang to build LLVM.
See [LLVM requirements](http://llvm.org/docs/GettingStarted.html#requirements) for more details.
+`build.cmd`/`build.sh` script downloads a pre-built ObjWriter NuGet package. ObjWriter library is not built by default because
+it takes a long time and changes rarely.
+
+To build a fresh ObjWriter, pass additional `objwriter` argument to the `build.cmd`/`build.sh` script. It will cause the build to clone
+a matching copy of LLVM and use it to build ObjWriter library.
+
+The following manual steps are useful for troubleshooting ObjWriter build issues.
+
1. Clone LLVM from official LLVM mirror github git repository:
```
@@ -12,7 +20,7 @@ See [LLVM requirements](http://llvm.org/docs/GettingStarted.html#requirements) f
2. Copy ObjWriter directory from CoreRT into LLVM tree
```
- cp -r CoreRT/src/Native/ObjWriter llvm/tools/
+ cp -r corert/src/Native/ObjWriter llvm/tools/
```
3. Apply the patch to LLVM:
diff --git a/Documentation/how-to-build-WebAssembly.md b/Documentation/how-to-build-WebAssembly.md
index 84e6ed6df..0f1845ff9 100644
--- a/Documentation/how-to-build-WebAssembly.md
+++ b/Documentation/how-to-build-WebAssembly.md
@@ -4,6 +4,7 @@
1. Install Emscripten by following the instructions [here](https://kripken.github.io/emscripten-site/docs/getting_started/downloads.html).
2. Follow the instructions [here](https://kripken.github.io/emscripten-site/docs/getting_started/downloads.html#updating-the-sdk) to update Emscripten to the latest version.
+3. Install [Firefox](https://www.getfirefox.com) (for testing).
3. Get CoreRT set up by following the [Visual Studio instructions](how-to-build-and-run-ilcompiler-in-visual-studio.md).
4. Build the WebAssembly runtime by running ```build.cmd wasm``` from the repo root.
5. Run the WebAssembly "Hello World" test by running ```C:\corert\tests\runtest.cmd wasm```.
@@ -36,6 +37,7 @@ This is Windows only for now.
# Useful tips #
* To manually make ILC compile to WebAssembly, add ```--wasm``` to the command line.
+* To debug C# source, add ```-g4``` to the emcc command line and change ```-s WASM=1``` to ```-s WASM=0```. This will generate a JavaScript source map that browser debuggers and Visual Studio Code can work with. Using Visual Studio Code's Chrome debugger works particularly well.
* Add ```-g3``` to the emcc command line to generate more debuggable output and a .wast file with the text form of the WebAssembly.
-* Omit ```-s WASM=1``` from the emcc command line to generate asm.js. Browser debuggers currently work better with asm.js and it's often a bit more readable than wast.
+* Change ```-s WASM=1``` to ```-s WASM=0``` in the emcc command line to generate asm.js. Browser debuggers currently work better with asm.js and it's often a bit more readable than wast.
* Add ```-O2 --llvm-lto 2``` to the emcc command line to enable optimizations. This makes the generated WebAssembly as much as 75% smaller as well as more efficient.
diff --git a/Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md b/Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md
index 48b1f3b47..d5b38f8ee 100644
--- a/Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md
+++ b/Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md
@@ -14,9 +14,9 @@ This will result in the following:
- Build native and managed components of ILCompiler. The final binaries are placed to `<repo_root>\bin\<OS>.<arch>.<Config>\tools`.
- Build and run tests
-# Install .NET Core 2.0 SDK
+# Install .NET Core 2.1 SDK
-* Download .NET Core 2.0 SDK from [https://www.microsoft.com/net/download/core](https://www.microsoft.com/net/download/core)
+* Download .NET Core 2.1 SDK from [https://www.microsoft.com/net/download/core](https://www.microsoft.com/net/download/core)
* On windows ensure you are using the 'x64 Native Tools Command Prompt for VS 2017'
(This is distinct from the 'Developer Command Prompt for VS 2017')
@@ -35,7 +35,7 @@ You should now be able to use the `dotnet` commands of the CLI tools.
<PropertyGroup>
<OutputType>Exe</OutputType>
- <TargetFramework>netcoreapp2.0</TargetFramework>
+ <TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<Import Project="$(MSBuildSDKsPath)\Microsoft.NET.Sdk\Sdk\Sdk.targets" />
@@ -61,7 +61,7 @@ From the shell/command prompt, issue the following commands, from the folder con
dotnet publish -r win-x64|linux-x64|osx-x64
```
-Native executable will be dropped in `./bin/x64/[configuration]/netcoreapp2.0/publish/` folder and will have the same name as the folder in which your source file is present.
+Native executable will be dropped in `./bin/x64/[configuration]/netcoreapp2.1/publish/` folder and will have the same name as the folder in which your source file is present.
## Using CPP Code Generator ##
@@ -93,7 +93,7 @@ If you are seeing errors such as:
```
libcpmtd.lib(nothrow.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' [C:\Users\[omitted]\nativetest\app\app.csproj]
-C:\Users\[omitted]\nativetest\bin\Windows_NT.x64.Debug\build\Microsoft.NETCore.Native.targets(151,5): error MSB3073: The command "link @"obj\Debug\netcoreapp1.0\native\link.rsp"" exited with code 1112. [C:\Users\[omitted]\nativetest\app\app.csproj]
+C:\Users\[omitted]\nativetest\bin\Windows_NT.x64.Debug\build\Microsoft.NETCore.Native.targets(151,5): error MSB3073: The command "link @"obj\Debug\netcoreapp2.1\native\link.rsp"" exited with code 1112. [C:\Users\[omitted]\nativetest\app\app.csproj]
```
or
diff --git a/Documentation/how-to-build-and-run-ilcompiler-in-vscode.md b/Documentation/how-to-build-and-run-ilcompiler-in-vscode.md
index e17ca9bbc..43bf635a9 100644
--- a/Documentation/how-to-build-and-run-ilcompiler-in-vscode.md
+++ b/Documentation/how-to-build-and-run-ilcompiler-in-vscode.md
@@ -49,7 +49,7 @@ dotnet build /t:LinkNative /t:Rebuild /v:Detailed | grep ".ilc.rsp"
Once you have the ilc path, you can change ```launch.json``` accordingly:
```json
- "args": ["@obj/Debug/netcoreapp1.0/native/<netcore_app_name>.ilc.rsp"],
+ "args": ["@obj/Debug/netcoreapp2.1/native/<netcore_app_name>.ilc.rsp"],
"cwd": "<netcore_app_root_folder>",
```
diff --git a/Documentation/how-to-run-tests.md b/Documentation/how-to-run-tests.md
index 9e43d1191..af747e28b 100644
--- a/Documentation/how-to-run-tests.md
+++ b/Documentation/how-to-run-tests.md
@@ -1,6 +1,6 @@
# Testing CoreRT
-The CoreRT test harness can run in two modes - with the tests local to the CoreRT repo, or with tests from the [CoreCLR](http://github.com/dotnet/coreclr) repo. The local tests only provide basic sanity testing and it's recommended to run the CoreCLR tests which are much more thorough.
+The CoreRT test harness can run in two modes - with the tests local to the CoreRT repo, with tests from the [CoreCLR](https://github.com/dotnet/coreclr) repo or the tests from the [CoreFX](https://github.com/dotnet/corefx) repo. The local tests only provide basic sanity testing and it's recommended to run the CoreCLR and CoreFX tests which are much more thorough.
The tests exercise both the runtime and the ILC compiler, which compiles IL into native code. The harness can test both the RyuJIT code generation backend, or the C++ backend of the ILC compiler.
@@ -33,37 +33,41 @@ CPP - TOTAL: 2 PASSED: 2
WASM - TOTAL: 1 PASSED: 1
```
-## External Tests
-
-*Note: These are currently supported only on Windows and Ubuntu/macOS support is coming soon.*
+## External Tests - CoreCLR
When runtest.cmd is passed the /coreclr switch, the harness will download the CoreCLR project's test suite, compile them to native with the CoreRT compiler, and run them.
### How To Run
Choose the set of tests you want to run. Currently the options are:
+
* Top200
- * Small set of the suite selected to provide broad coverage quickly (Under 10 minutes). These run as part of the CI when submitting a pull request.
+ * Small set of the suite selected to provide broad coverage quickly (Under 10 minutes). These run as part of the CI when submitting a pull request.
* KnownGood
- * Subset of the suite previously validated to all pass on CoreRT. If these all pass you can be pretty sure you haven't regressed the compiler.
+ * Subset of the suite previously validated to all pass on CoreRT. If these all pass you can be pretty sure you haven't regressed the compiler. We currently only have a KnownGood list on Windows.
* All
- * The entire suite. Many of the tests will fail since CoreRT is still pre-release and some tests don't play well with an ahead-of-time compiler.
+ * The entire suite. Many of the tests will fail since CoreRT is still pre-release and some tests don't play well with an ahead-of-time compiler.
On Windows:
+
```
tests\runtest.cmd /coreclr Top200|All|KnownGood
```
On Linux / macOS:
+```
tests/runtest.sh -coreclr Top200|All|KnownGood
+```
### Suppress Windows Error Reporting Dialogs
+
It's advisable to use some sort of a dialog killer tool if you see test regressions as many tests fail with pop-ups for Windows Error Reporting. However, the following regedit scripts have also proven to be useful to mask these pop-ups.
Disable WER *temporarily*:
**Contents of disable-wer.reg**
+
```
REGEDIT4
@@ -75,6 +79,7 @@ REGEDIT4
Remember to enable:
**Contents of enable-wer.reg**
+
```
REGEDIT4
@@ -84,9 +89,75 @@ REGEDIT4
```
### Filtering Tests
+
If you know a test is failing for a good reason or you want a clean baseline, please use ```corert\tests\KnownGood.CoreCLR.issues.targets``` to weed out bad tests or infrastructure errors until we fix them.
### Test Logs
+
When the tests finish execution, the log location will be written out and should be in bin\Logs:
**Example:** ```corert\bin\Logs\TestRun_Windows_NT__x64__debug.html```
+
+## External tests - CoreFX
+
+Similarly to the CoreCLR tests, when runtest.cmd is passed the /corefx switch, the harness will download the CoreFX project's test suite, compile them to native with the CoreRT compiler, and run them.
+
+### How to run
+
+To run CoreFX tests on CoreRT, make sure that `build.cmd` has been run at least once in the configuration you'd like to test (i.e. `Debug` or `Release`), open a new console window and from the repo root execute the following:
+
+On Windows:
+
+```
+tests\runtest.cmd /corefx
+```
+
+On Linux / macOS:
+
+```
+tests/runtest.sh -corefx
+```
+
+The tests assemblies to run are defined in `TopN.CoreFX.[Windows/Unix].issues.json` with their respectively excluded test methods, classes or namespaces.
+
+### Reproducing test failures
+
+If you need to reproduce a failing test, navigate to ```test_downloaded\CoreFX``` and then to the folder of the failing test - each test suite is located in its own folder. From the test suite directory run the following:
+
+On Windows:
+
+```
+.\native\xunit.console.netcore.exe .\<name of the main test assembly> @"./<name of the main test assembly>.rsp" -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -notrait category=failing
+```
+
+On Linux / macOS:
+
+```
+./native/xunit.console.netcore.exe ./<name of the main test assembly> @"./<name of the main test assembly>.rsp" -notrait category=nonnetcoreapptests -notrait category=failing
+```
+
+Additionally for Linux, add `-notrait category=nonlinuxtests` and for macOS `-notrait category=nonosxtests`.
+
+**e.g.** for System.Collections.Tests on Windows:
+
+Navigate to C:\repos\corert\test_downloaded\CoreFX\System.Collections.Tests.
+Open Command Promps and run:
+
+```
+.\native\xunit.console.netcore.exe .\System.Collections.Tests.dll `@"System.Collections.Tests.rsp" -notrait category=nonnetcoreapptests -notrait category=nonwindowstests -notrait category=failing
+```
+
+### Enabling tests
+
+To enable a new CoreFX test project to run against CoreRT add its fully qualified name to `TopN.CoreFX.[Windows/Unix].issues.json`.
+To remove a test from a test project which is already enabled, in the same file find and delete the definition containing its name.
+
+### Disabling tests
+
+Tests can be excluded from a run in the following ways:
+
+* To exclude a specific test method, add its fully-qualified name in the `method` array of the `exclusions` attribute of relevant test project or pass it as a value to the `-skipmethod` flag when calling `xunit.console.netcore.exe`.
+
+* To exclude all tests in a class, add its fully-qualified name in the `class` array of the `exclusions` attribute of relevant test project or pass it as a value to the `-skipclass` flag when calling `xunit.console.netcore.exe`.
+
+* To exclude all tests in a class, add its fully-qualified name in the `namespace` array of the `exclusions` attribute of relevant test project or pass it as a value to the `-skipnamespace` flag when calling `xunit.console.netcore.exe`.
diff --git a/Documentation/intro-to-corert.md b/Documentation/intro-to-corert.md
index 775d6fd77..8bc78a14d 100644
--- a/Documentation/intro-to-corert.md
+++ b/Documentation/intro-to-corert.md
@@ -1,19 +1,21 @@
-Intro to .NET Native and CoreRT
-===============================
+Intro to CoreRT
+===============
-Native compilation is a great scenario addition to .NET Core apps on Windows, OS X and Linux. We've seen significant startup and throughput benefits of native compilation for Windows UWP apps, using .NET Native. Today, many native apps and tools benefit from being compiled by a C++ compiler, and not as much by being written in C++. .NET Native brings much of the performance and all of the deployment benefits of native compilation, while retaining your ability to write in your favorite .NET programming language.
+Native (AOT) compilation is a great scenario addition to .NET Core apps on Windows, OS X and Linux. We've seen significant startup and throughput benefits of native compilation for Windows UWP apps, using .NET Native. Today, many native apps and tools benefit from being compiled by a C++ compiler, and not as much by being written in C++. CoreRT brings much of the performance and all of the deployment benefits of native compilation, while retaining your ability to write in your favorite .NET programming language.
Architecture
============
-[.NET Native](https://msdn.microsoft.com/library/dn584397.aspx) is a native toolchain that compiles [CIL byte code](https://en.wikipedia.org/wiki/Common_Intermediate_Language) to machine code (e.g. X64 instructions). By default, .NET Native (for .NET Core, as opposed to UWP) uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler. It can also be used with other compilers, such as [LLILC](https://github.com/dotnet/llilc), UTC for UWP apps and [IL to CPP](https://github.com/dotnet/corert/tree/master/src/ILCompiler.CppCodeGen/src/CppCodeGen) (an IL to textual C++ compiler we have built as a reference prototype).
+[CoreRT](https://github.com/dotnet/corert) is a native toolchain that compiles [CIL byte code](https://en.wikipedia.org/wiki/Common_Intermediate_Language) to machine code (e.g. X64 instructions). By default, CoreRT uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler. CoreRT can also be used with other compilers, such as [LLILC](https://github.com/dotnet/llilc), and [IL to CPP](https://github.com/dotnet/corert/tree/master/src/ILCompiler.CppCodeGen/src/CppCodeGen) (an IL to textual C++ compiler we have built as a reference prototype). [.NET Native](https://docs.microsoft.com/en-us/dotnet/framework/net-native/index) uses CoreRT in conjunction with the UTC compiler to provide native compilation for UWP apps.
-[CoreRT](https://github.com/dotnet/corert) is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets. This is a refactored and layered runtime. The base is a small native execution engine that provides services such as garbage collection(GC). This is the same GC used in CoreCLR. Many other parts of the traditional .NET runtime, such as the [type system](https://github.com/dotnet/corert/tree/master/src/Common/src/TypeSystem), are implemented in C#. We've always wanted to implement runtime functionality in C#. We now have the infrastructure to do that. In addition, library implementations that were built deep into CoreCLR, have also been cleanly refactored and implemented as C# libraries.
+CoreRT is a refactored and layered .Net Core runtime. The base is a small native execution engine that provides services such as garbage collection(GC). This is the same GC used in CoreCLR. Many other parts of the traditional .NET runtime, such as the [type system](https://github.com/dotnet/corert/tree/master/src/Common/src/TypeSystem), are implemented in C#. We've always wanted to implement runtime functionality in C#. We now have the infrastructure to do that. In addition, library implementations that were built deep into CoreCLR, have also been cleanly refactored and implemented as C# libraries.
+
+For more information about the architecture, see http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT/ .
Experience
==========
-.NET Native offers great benefits that are critical for many apps.
+CoreRT offers great benefits that are critical for many apps.
- The native compiler generates a *SINGLE FILE*, including the app, managed dependencies and CoreRT.
- Native compiled apps startup faster since they execute already compiled code. They don't need to generate machine code at runtime nor load a JIT compiler.
diff --git a/Documentation/prerequisites-for-building.md b/Documentation/prerequisites-for-building.md
index 368e8f4cd..77f31366f 100644
--- a/Documentation/prerequisites-for-building.md
+++ b/Documentation/prerequisites-for-building.md
@@ -20,7 +20,7 @@ sudo apt-get update
```
```sh
-sudo apt-get install cmake clang-3.9 libicu52 libunwind8 uuid-dev libcurl4-openssl-dev zlib1g-dev
+sudo apt-get install cmake clang-3.9 libicu52 libunwind8 uuid-dev libcurl4-openssl-dev zlib1g-dev libkrb5-dev
```
# macOS (10.12+)
@@ -59,5 +59,5 @@ sudo apt-get update
```
```sh
-sudo apt-get install cmake clang-3.9 libunwind8 uuid-dev
+sudo apt-get install cmake clang-3.9 libunwind8 uuid-dev libcurl4-openssl-dev zlib1g-dev libkrb5-dev
```