mono/linux-packaging-mono
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Imported Upstream version 5.10.0.69

Browse Source 
Former-commit-id: fc39669a0b707dd3c063977486506b6793da2890
This commit is contained in:
Xamarin Public Jenkins (auto-signing)
2018-01-29 19:03:06 +00:00
parent d8f8abd549
commit e2950ec768
6283 changed files with 453847 additions and 91879 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
external/corert/Documentation/README.md vendored
View File

@@ -15,3 +15,4 @@ This is the repo for CoreRT, the .NET Core runtime optimized for AOT (Ahead of T
- [How to build and run from VSCode](how-to-build-and-run-ilcompiler-in-vscode.md)
- [How to run tests](how-to-run-tests.md)
- [Cross Compilation for ARM on Linux](cross-building.md)
- [How to Build WebAssembly](how-to-build-WebAssembly.md)

60
external/corert/Documentation/cross-building.md vendored
View File

@@ -1,7 +1,7 @@
Cross Compilation for ARM on Linux
==================================
Through cross compilation, on Linux it is possible to build CoreCLR for arm or arm64.
Through cross compilation, on Linux it is possible to build CoreRT for arm or arm64.
Requirements
------------
@@ -21,7 +21,7 @@ and conversely for arm64:
Generating the rootfs
---------------------
The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an Ubuntu 14.04 rootfs as this is what CoreCLR targets.
The `cross\build-rootfs.sh` script can be used to download the files needed for cross compilation. It will generate an Ubuntu 14.04 rootfs as this is what CoreRT targets.
Usage: build-rootfs.sh [BuildArch]
BuildArch can be: arm, arm64
@@ -38,7 +38,7 @@ and if you wanted to generate the rootfs elsewhere:
Cross compiling CoreCLR
-----------------------
Once the rootfs has been generated, it will be possible to cross compile CoreCLR. If `ROOTFS_DIR` was set when generating the rootfs, then it must also be set when running `build.sh`.
Once the rootfs has been generated, it will be possible to cross compile CoreRT. If `ROOTFS_DIR` was set when generating the rootfs, then it must also be set when running `build.sh`.
So, without `ROOTFS_DIR`:
@@ -49,3 +49,57 @@ And with:
$ ROOTFS_DIR=~/coreclr-cross/arm ./build.sh arm debug verbose clean cross
As usual the resulting binaries will be found in `bin/Product/BuildOS.BuildArch.BuildType/`
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).
1. Build CoreCLR for x86 (`checked` version)
```
sudo ./cross/build-rootfs.sh x86 xenial
./build.sh clang3.9 x86 checked verbose cross skiptests
```
2. Build CoreFX (`Debug` version)
3. Build CoreRT for armel, x64, x86
```
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
```
4. Copy necessary binaries to working directory (in x86 rootfs)
```
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
cp -r ${CORERT}/bin/Linux.armel.Debug/sdk ${WORKING_DIR}
```
5. Rename RyuJIT compiler library
```
# Use cross-compiler library as default for ILC
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:
```
./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
# 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
```

51
external/corert/Documentation/design-docs/WebAssembly-design.md vendored Normal file
View File

@@ -0,0 +1,51 @@
# WebAssembly Design
WebAssembly (WASM) is a rapidly evolving platform and significantly different than the ones that .NET already supports. CoreRT is in a good position to target new and different architectures due to its pluggable compiler design and because most of it is written in architecture-independent C#. Many high-level .NET features will hopefully work without modification. The important WASM-specific areas we've considered so far are below.
## Code Generation
For WASM code generation, CoreRT plugs into LLVM's APIs to generate LLVM bitcode. That bitcode can be linked by [Emscripten](http://kripken.github.io/emscripten-site/) into WebAssembly, as well as ASM.js. The reasons for this design are:
1. While it may be possible to create a WASM RyuJIT target architecture, that's likely fairly expensive to get working and even more expensive to build WASM-specific optimizations for. If WASM becomes a major .NET usage scenario, we'd likely revisit this.
2. Emscripten includes a combination of general LLVM optimizations (like eliminating redundant assignments) and WASM-specific optimizations (like controlling the JavaScript optimizer).
3. Compiling with LLVM gives managed code the ability to call into C code, which is valuable for calls into the .NET or C runtimes.
4. An LLVM bitcode generator in CoreRT might be usable for quick ports to future platforms before RyuJIT is ready for them.
### Details
Working via LLVM bitcode implies that some IL concepts need to be translated to C-like concepts. In particular:
1. .NET requires visibility into its stack layout for garbage collection and exception handling. WebAssembly does not allow pointers to the stack at all and LLVM has some limitations on what's available. To get sufficient control over the stack, CoreRT manages its own "shadow" stack that is allocated on the C heap. That also means methods have a custom calling convention. Every method call pushes managed arguments onto the shadow stack, followed by a space for the return value. The method signature fed to LLVM is always the same: void MethodName(int8* ArgumentPointer, int8* ReturnArgumentAddress). This will also allow delegates and reflection to call arbitrary methods without special codegen per-signature.
2. IL includes implicit conversion between various integer and pointer types. For example, the C# code:
```
int b = 0;
fixed(int* a = &b)
{
int* c = a + 1;
}
```
Translates into IL something like:
```
ldloc.a b // Loads an int&
stloc a // stores into a native int
ldloc a // loads a native int
ldc 1 // loads an int32
add // produces a native int
```
Since those implicit conversions are illegal in C, every load/push operation must convert to canonical types and every store/pop operation must convert to the target type.
3. LLVM's internal representation is strongly typed, but because the C++ rules are different than .NET rules, we only want minimal integration with LLVM's strong typing. To handle that, all .NET types are canonicalized to a small set of LLVM types. Numeric types map directly while structs are mapped to Int8 arrays matching the struct's size. Classes are represented as Int8 pointers.
## Framework Libraries
Many framework libraries should work without modification. However, some APIs (such as files and networking) are platform-dependent. CoreRT and CoreFX include a Platform Abstraction Layer (PAL) built for each supported platform. We will need a WebAssembly PAL that calls into the right C or JavaScript APIs to support functionality. JavaScript sandboxing will limit some operations (such as which network calls are permitted).
## Garbage Collection
The WebAssembly working group is discussing proposals to include garbage collector object reporting, but that's not yet complete and it's not entirely clear if it will work for .NET. While work has not started on enabling the garbage collector, the intent is that the "shadow stack" will provide enough control for stackwalks that perform precise GC reporting.
## Exception Handling
This will need further investigation. The C++ compiler does allow exception handling, although it requires special checks in methods with catch blocks. We may be able to build something similar. The WebAssembly working group has also proposed "zero-cost" exceptions (ones that don't need special checks), but it's not yet clear what that will look like or if it will work for the .NET two-pass exception handling model.
## Interoperability
Interop with C code should work similarly to P/Invokes today with the possible exception of needing to statially link C libraries instead of calling them dynamically. We likely will need to define a JavaScript interop model as well to provide interaction with the rest of the web page.
## Debugging
There is currently very little debugging support for WebAssembly built into browsers. We'll probably need to watch as this expands to understand what's available for CoreRT.
## Threading
WebAssembly does not currently support threading, although there are some proposals under consideration. If WebAssembly does not adopt threading in a timely manner, CoreRT may be able to inject context-switching code into compiled code.

12
external/corert/Documentation/engineering/updating-ryujit.md vendored Normal file
View File

@@ -0,0 +1,12 @@
# Updating RyuJIT
Following steps are necessary to pick up a new version of RyuJIT code generation backend from CoreCLR:
1. From the master branch of the CoreCLR repo, copy header files that are part of the contract with RyuJIT from `src\inc` on the CoreCLR side, to `src\JitInterface\src\ThunkGenerator` on the CoreRT side.
2. Inspect the diffs
1. If an enum was modified, port the change to the managed version of the enum manually.
2. If a JitInterface method was added or changed, update `src\JitInterface\src\ThunkGenerator\ThunkInput.txt` and run the generation script next to the file to regenerate `CorInfoBase.cs` and `jitinterface.h`. Update the managed implementation of the method in `CorInfoImpl.cs` manually.
3. If the JitInterface GUID was updated, update it in `src\Native\jitinterface\jitwrapper.cpp`
3. Go to https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.Jit and find the latest version of the RyuJIT package. Update the version number in dependencies.props at the root of the repo.
4. Rebuild everything and run tests to validate the change.
5. Create a pull request with title "Update RyuJIT".

44
external/corert/Documentation/how-to-build-ObjectWriter.md vendored Normal file
View File

@@ -0,0 +1,44 @@
# Build ObjectWriter library #
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.
1. Clone LLVM from official LLVM mirror github git repository:
```
git clone -b release_50 https://github.com/llvm-mirror/llvm.git
```
2. Copy ObjWriter directory from CoreRT into LLVM tree
```
cp -r CoreRT/src/Native/ObjWriter llvm/tools/
```
3. Apply the patch to LLVM:
```
cd llvm
git apply tools/ObjWriter/llvm.patch
```
4. Configure and build LLVM with ObjWriter:
```
mkdir build
cd build
cmake ../ -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=1 -DHAVE_POSIX_SPAWN=0 -DLLVM_ENABLE_PIC=1 -DLLVM_BUILD_TESTS=0 -DLLVM_ENABLE_DOXYGEN=0 -DLLVM_INCLUDE_DOCS=0 -DLLVM_INCLUDE_TESTS=0
make -j10 objwriter
cd ..
```
* For ARM(cross/non-cross) please specify Triple for LLVM as Cmake configuration option:
```
-DLLVM_DEFAULT_TARGET_TRIPLE=thumbv7-linux-gnueabi
```
* You can change the building type(CMAKE_BUILD_TYPE) to the debugging type(Debug), if necessary to debug ObjWriter.
* Also, you can do this under chroot to building ObjWriter for other platforms.
5. Get ObjWriter:
If all goes well, the build will complete in the previous step and you will get ObjWriter library as llvm/build/lib/libobjwriter.so

22
external/corert/Documentation/how-to-build-WebAssembly.md vendored Normal file
View File

@@ -0,0 +1,22 @@
# Build WebAssembly #
Currently, building WebAssembly is only possible on Windows.
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. 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```.
To debug compiling WebAssembly:
1. Set the ILCompiler startup command line to ```@C:\corert\tests\src\Simple\HelloWasm\obj\Debug\wasm\native\HelloWasm.ilc.rsp```. That will generate HelloWasm.bc, an LLVM bitcode file.
2. To compile that to WebAssembly, run ```emcc HelloWasm.bc -s ALLOW_MEMORY_GROWTH=1 C:\corert\bin\WebAssembly.wasm.Debug\sdk\libPortableRuntime.bc C:\corert\bin\WebAssembly.wasm.Debug\sdk\libbootstrappercpp.bc -s WASM=1 -o HelloWasm.html``` (if emcc isn't on your path, you'll need to launch an Emscripten command prompt to do this). That will generate a .wasm file with your code as well as html and js files to run it.
To run a WebAssembly application
1. Ensure you have Edge 41 or above or [Firefox](https://www.getfirefox.com).
2. Open the generated html file in Edge or Firefox and look at the on-screen console for output.
Useful tips:
* To manually make ILC compile to WebAssembly, add ```--wasm``` to the command line.
* 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.
* 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.

52
external/corert/Documentation/how-to-build-and-run-ilcompiler-in-console-shell-prompt.md vendored
View File

@@ -8,18 +8,16 @@ Build your repo by issuing the following command at repo root:
build[.cmd|.sh] clean [Debug|Release]
```
If you're using Visual Studio 2017, you need to run the above command from the "Developer Command Prompt for VS 2017". Visual Studio setup puts a shortcut to this in the Start menu.
This will result in the following:
- Restore nuget packages required for building
- Build native and managed components of ILCompiler. The final binaries are placed to `<repo_root>\bin\Product\<OS>.<arch>.<Config>\packaging\publish1`.
- 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 latest CLI tools
# Install .NET Core 2.0 SDK
* Download latest CLI tools from [https://github.com/dotnet/cli/](https://github.com/dotnet/cli/) and add them to the path. The latest CLI tools include MSBuild support that the native compilation build integration depends on. These instructions have been tested with build `1.0.0-rc4-004812`.
* On windows ensure you are using the 'x64 Native Tools Command Prompt for VS 2017' or 'VS2015 x64 Native Tools Command Prompt'
* Download .NET Core 2.0 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')
You should now be able to use the `dotnet` commands of the CLI tools.
@@ -28,7 +26,7 @@ You should now be able to use the `dotnet` commands of the CLI tools.
* Ensure that you have done a repo build per the instructions above.
* Create a new folder and switch into it.
* Run `dotnet new` on the command/shell prompt. This will add a project template. If you get an error, please ensure the [pre-requisites](prerequisites-for-building.md) are installed.
* Run `dotnet new console` on the command/shell prompt. This will add a project template. If you get an error, please ensure the [pre-requisites](prerequisites-for-building.md) are installed.
* Modify `.csproj` file that is part of your project. A few lines at the top and at the bottom are different from the default template.
```
@@ -37,23 +35,21 @@ You should now be able to use the `dotnet` commands of the CLI tools.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<Import Project="$(MSBuildSDKsPath)\Microsoft.NET.Sdk\Sdk\Sdk.targets" />
<Import Project="$(IlcPath)\Microsoft.NETCore.Native.targets" />
<Import Project="$(IlcPath)\build\Microsoft.NETCore.Native.targets" />
</Project>
```
* Set IlcPath environment variable to point to the built binaries. Alternatively, pass an extra `/p:IlcPath=<repo_root>\bin\Product\Windows_NT.x64.Debug\packaging\publish1` argument to all dotnet commands below.
* Set IlcPath environment variable to point to the built binaries. Alternatively, pass an extra `/p:IlcPath=<repo_root>\bin\Windows_NT.x64.Debug` argument to all dotnet commands below.
* Unix: `export IlcPath=<repo_root>/bin/Product/Linux.x64.Debug/packaging/publish1`
* Unix: `export IlcPath=<repo_root>/bin/Linux.x64.Debug`
* Windows: `set IlcPath=<repo_root>\bin\Product\Windows_NT.x64.Debug\packaging\publish1`
* Windows: `set IlcPath=<repo_root>\bin\Windows_NT.x64.Debug`
* Run `dotnet restore`. This will download nuget packages required for compilation.
* Please [open an issue](https://github.com/dotnet/corert/issues) if these instructions do not work anymore. .NET Core integration with MSBuild is work in progress and these instructions need updating accordingly from time to time.
* Please [open an issue](https://github.com/dotnet/corert/issues) if these instructions do not work anymore.
## Using RyuJIT ##
@@ -62,23 +58,27 @@ This approach uses the same code-generator (RyuJIT), as [CoreCLR](https://github
From the shell/command prompt, issue the following commands, from the folder containing your project, to generate the native executable
```
dotnet build /t:LinkNative
dotnet publish -r win-x64|linux-x64|osx-x64
```
Native executable will be dropped in `./bin/[configuration]/native/` 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.0/publish/` folder and will have the same name as the folder in which your source file is present.
## Using CPP Code Generator ##
This approach uses platform specific C++ compiler and linker for compiling/linking the application.
This approach uses [transpiler](https://en.wikipedia.org/wiki/Source-to-source_compiler) to convert IL to C++, and then uses platform specific C++ compiler and linker for compiling/linking the application. The transpiler is a lot less mature than the RyuJIT path. If you came here to give CoreRT a try on your .NET Core program, use the RyuJIT option above.
From the shell/command prompt, issue the following commands to generate the native executable:
```
dotnet build /t:LinkNative /p:NativeCodeGen=cpp
dotnet publish /p:NativeCodeGen=cpp -r win-x64|linux-x64|osx-x64
```
For CoreRT debug build on Windows, add an extra `/p:AdditionalCppCompilerFlags=/MTd` argument.
## Disabling Native Compilation
Native compilation can be disabled during publishing by adding an extra `/p:NativeCompilationDuringPublish=false` argument.
## Workarounds for build errors on Windows ##
If you are seeing errors such as:
@@ -93,7 +93,19 @@ 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\Product\Windows_NT.x64.Debug\packaging\publish1\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\netcoreapp1.0\native\link.rsp"" exited with code 1112. [C:\Users\[omitted]\nativetest\app\app.csproj]
```
or
```
Microsoft.NETCore.Native.targets(150,5): error MSB3073: The command "link @"native\link.rsp"" exited with code 1.
```
or
```
Microsoft.NETCore.Native.targets(132,5): error MSB3073: The command "cl @"native\cl.rsp"" exited with code 9009.
```
Make sure you run these commands from the `x64 Native Tools Command Prompt for VS 2017` instead of a vanilla command prompt

18
external/corert/Documentation/how-to-build-and-run-ilcompiler-in-visual-studio.md vendored
View File

@@ -4,15 +4,19 @@ _Note_:
* Instructions below assume `c:\corert` is the repo root.
# Build ILCompiler #
Build your repo by issuing the following command at repo root:
# Building ILCompiler in Visual Studio 2017 #
First, build your repo by issuing the following command at repo root, by default this builds Debug x64:
```
build.cmd
```
Then when building ILCompiler.sln in Visual Studio, remember to select the appropriate configuration that you built. By default, `build.cmd` builds Debug x64 and so `Debug` and `x64` must be selected in the solution build configuration drop downs.
If you changed `c:\corert\src\ILCompiler\repro\project.json`
---
If you changed `c:\corert\src\ILCompiler\repro\repro.csproj`
```
build.cmd clean
@@ -24,7 +28,7 @@ _Note: The size of NuGet packages is approximately 2.75 GB, so download might ta
1. Open c:\corert\src\ILCompiler\ILCompiler.sln in VS
- Set "desktop" project in solution explorer as your startup project
- Set "ILCompiler" project in solution explorer as your startup project
- Set startup command line to:
`@c:\corert\bin\obj\Windows_NT.x64.Debug\ryujit.rsp`
@@ -47,7 +51,7 @@ _Note: The size of NuGet packages is approximately 2.75 GB, so download might ta
1. Open `c:\corert\src\ILCompiler\ILCompiler.sln` in VS
- Set "desktop" project in solution explorer as your startup project
- Set "ILCompiler" project in solution explorer as your startup project
- Set startup command line to:
`@c:\corert\bin\obj\Windows_NT.x64.Debug\cpp.rsp`
@@ -63,3 +67,7 @@ _Note: The size of NuGet packages is approximately 2.75 GB, so download might ta
- Set breakpoint at repro::Program::Main in main.cpp
- Build, run & step through as with any other C++ program
## Writing your repro code in IL ##
If you want to write your repro code using IL (instead of C#), you can search/replace `"repro\repro.csproj"` to `"repro\repro.ilproj"` in ILCompiler.sln which switches to repro.ilproj instead of repro.csproj. Just write your IL code in `repro.il` and build/debug as usual. All the instructions above still would work as expected. Just make sure don't check-in that change.

7
external/corert/Documentation/how-to-build-and-run-ilcompiler-in-vscode.md vendored
View File

@@ -25,11 +25,14 @@ And then press SHIFT+COMMAND+B to start the build.
Go to the debug pane and click Debug, choose .NET Core as the environment. If needed, you can change program property in launch.json (the gear button) to point to a different flavor of ilc:
```json
"windows": {
"program": "${workspaceRoot}/bin/Windows_NT.x64.Debug/tools/ilc.dll"
},
"osx": {
"program": "${workspaceRoot}/bin/Product/OSX.x64.Debug/packaging/publish1/ilc.dll"
"program": "${workspaceRoot}/bin/OSX.x64.Debug/tools/ilc.dll"
},
"linux": {
"program": "${workspaceRoot}/bin/Product/Linux.x64.Debug/packaging/publish1/ilc.dll"
"program": "${workspaceRoot}/bin/Linux.x64.Debug/tools/ilc.dll"
},
```

37
external/corert/Documentation/how-to-debug-compiler-dependency-analysis.md vendored Normal file
View File

@@ -0,0 +1,37 @@
Debugging Compiler Dependency Analysis
============================
The general technique is to identify what node is missing from the graph or is erroneously present in the graph, and change the dependency analysis logic to adjust the graph. This document describes the various ways of debugging to identify what's happening.
Analysis techniques for the dependency graph.
1. Use the ILCompiler-DependencyGraph-Viewer tool (if running on Windows). This tool is located in src\ILCompiler.DependencyAnalysisFramework\ILCompiler-DependencyGraph-Viewer
- This is the only convenient way to examine the graph while also simultaneously debugging the compiler.
- While this is currently Windows only due to use of WinForms, it would be fairly straightforward to make a command line based tool.
2. Pass command line switches to the compiler to generate a dependency graph dgml file. This will produce the same data as is viewable in the viewer tool, but in a textual xml format.
- Future efforts may make the xml file loadable by the viewer tool.
3. Instrument the compiler dependency analysis. (This may be necessary in cases where the viewer is unable to provide sufficient information about why the graph is structured as it is.)
ILCompiler-DependencyGraph-Viewer
====================================
This application allows viewing the dependency graph produced by the CoreRT compilation.
Usage instructions:
1. Launch the process as an administrator
2. Run the compiler
- The compiler can be run to completion, or stopped.
3. Explore through the graph
# Graphs View #
- Choose one of the graphs that appears in the Dependency Graphs view to explore. As compilers execute, new graphs will automatically appear here.
- The set of graphs loaded into the process is limited by available memory space. To clear the used memory, close all windows of the application.
# Graph View #
- In the Dependency Graph view, enter a regular expression in the text box, and then press ""Filter"". This will display a list of the nodes in the graph which have names which match the regular expression.
- Commonly, if there is a object file symbol associated with the node it should be used as part of the regular expression. See the various implementations of GetName in the compiler for naming behavior.
- Additionally, the event source marking mode assigns an Id to each node, and that is found as the mark object on the node, so if a specific id is known, just type that in, and it will appear in the window. (This is for use when using this tool in parallel with debugging the compiler.
# Single Node Exploration #
Once the interesting node(s) have been identified in the dependency graph window, select one of them, and then press Explore.
- In the Node Explorer window, the Dependent nodes (the ones which dependend on the current node are the nodes displayed above, and the Dependee nodes (the nodes that this node depends on) are displayed below. Each node in the list is paired with a textual reason as to why that edge in the graph exists.
- Select a node to explore further and press the corresponding button to make it happen.

4
external/corert/Documentation/intro-to-corert.md vendored
View File

@@ -6,7 +6,7 @@ Native compilation is a great scenario addition to .NET Core apps on Windows, OS
Architecture
============
[.NET Native](https://msdn.microsoft.com/library/dn584397.aspx) is a native toolchain that compiles [IL 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).
[.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 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.
@@ -27,4 +27,4 @@ These benefits open up some new scenarios for .NET developers
Roadmap
=======
To start, we are targeting native executables (AKA "console apps"). Over time, we'll extend that to include ASP.NET 5 apps. You can continue to use CoreCLR for your .NET Core apps. It remains a great option if native compilation isn't critical for your needs. CoreCLR will also provide a superior debugging experience until we add debugging support to CoreRT.
To start, we are targeting native executables (AKA "console apps"). Over time, we'll extend that to include ASP.NET Core apps. You can continue to use CoreCLR for your .NET Core apps. It remains a great option if native compilation isn't critical for your needs. CoreCLR will also provide a superior debugging experience until we add debugging support to CoreRT.

10
external/corert/Documentation/prerequisites-for-building.md vendored
View File

@@ -2,13 +2,13 @@ The following pre-requisites need to be installed for building the repo:
# Windows (Windows 7+)
1. Install [Visual Studio 2017](https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx), including Visual C++ support. Visual Studio 2015 also works.
1. Install [Visual Studio 2017](https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx), including Visual C++ support.
2. Install [CMake](http://www.cmake.org/download/) 3.8.0 or later. Make sure you add it to the PATH in the setup wizard.
3. (Windows 7 only) Install PowerShell 3.0. It's part of [Windows Management Framework 3.0](http://go.microsoft.com/fwlink/?LinkID=240290). Windows 8 or later comes with the right version inbox.
PowerShell also needs to be available from the PATH environment variable (it's the default). Typically it should be %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\.
# Ubuntu (14.04)
# Ubuntu (14.04+)
Install basic dependency packages:
@@ -23,12 +23,10 @@ sudo apt-get update
sudo apt-get install cmake clang-3.9 libicu52 libunwind8 uuid-dev
```
# Mac OSX (10.11.5+)
# macOS (10.12+)
1. Install [Command Line Tools for XCode 8](https://developer.apple.com/xcode/download/) or higher.
2. Install [CMake](https://cmake.org/download/). Launch `/Applications/CMake.app/Contents/MacOS/CMake` GUI. Goto "OSX App Menu -> Tools -> Install For Command Line Use" and follow the steps. CMake < 3.6 has [a bug](https://cmake.org/Bug/view.php?id=16064) that can make `--install` fail. Do `sudo mkdir /usr/local/bin` to work around.
3. Install OpenSSL. Build tools have a dependency on OpenSSL. You can use [Homebrew](http://brew.sh/) to install it: with Homebrew installed, run `brew install openssl` followed by `ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/`, followed by `ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/`.
4. Install ICU (International Components for Unicode). It can be obtained via [Homebrew](http://brew.sh/): run `brew install icu4c` followed by `brew link --force icu4c`
2. Install [CMake](https://cmake.org/download/) 3.8.0 or later. Launch `/Applications/CMake.app/Contents/MacOS/CMake` GUI. Goto "OSX App Menu -> Tools -> Install For Command Line Use" and follow the steps.
# Bash on Ubuntu on Windows (Windows 10 Creators Update or later)