| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Removes unused native symbol references from the native binary
Fixes #6191
|
|
Runtime configuration (e.g. whether to use server GC) can currently be provided either through environment variables at runtime, or through a RhConfig.ini file placed next to the executable. This adds another channel where we burn a blob similar to RhConfig.ini format into the executable. The order of precedence is environment variable > RhConfig.ini > embedded config.
The `ServerGarbageCollection` project property that is used to determine whether to link with a runtime that supports server GC will be also used to control whether to generate a configuration that enables server GC at runtime by default.
Fixes #6100.
|
|
This makes it easier to work around #5496
|
|
|
|
And remove workaround that was trying to avoid dependency on `ConstrainedCallSupport_GetStubs`.
|
|
if filesystem is case sensitive gss must be GSS.
|
|
Adds an `--appcontextswitch` argument to the compiler (and accompanying `AppContextSwitchOverrides` MSBuild `ItemGroup`) to influence class library behaviors.
|
|
Contributes to #5662. Still not putting that library under a `Condition = Exe` because I'm not quite sure how many concepts `System.Private.DeveloperExperience.Console` is conflating (it doesn't seem like it's doing only what the name implies).
I'm doing this mostly so that the compiler is more hack-friendly for an after work project of mine.
|
|
|
|
Link the native exe in the Windows subsystem when the output type is WinExe on windows, and fallback to regular Exe behavior off-windows.
|
|
Selectively porting a line from #5651 to unblock an issue reported on Gitter.
|
|
Code to call InitializeModules on startup and associated bug fixes and workarounds. Handles mismatched struct calling conventions between LLVM and Clang and works around the dup opcode incorrectly reloading values. Enables StartupCodeMain and fix associated bugs in pinvokes. Implements main return codes
|
|
|
|
|
|
correctly (#5589)
Fixes #5096.
|
|
* Substitute pdb files
* Change Comment and pdb copying condition
|
|
Make the Server GC an optional component by building two flavors of the runtime and selecting a specific one in the build via the `ServerGarbageCollection` MSBuild property. Don't build the Server GC flavor for Web Assembly.
Fixes #5182, Fixes #5306.
|
|
Related to https://github.com/dotnet/coreclr/pull/16643
|
|
* Automatically execute WebAssembly tests on Windows by using emrun to launch a headless instance of Firefox (which doesn't interfere with any other Firefox usage). This should cut down on manual testing and help us move toward CI integration.
|
|
I was setting up a new machine today so I played with a "new user" experience.
Before this change, `dotnet publish` without VS installed would result in a message like
```
C:\Users\michals\.nuget\packages\microsoft.dotnet.ilcompiler\1.0.0-alpha-26216-01\build\Microsoft.NETCore.Native.Windows.props(83,5): error MSB3073: The command ""C:\Users\michals\.nuget\packages\microsoft.dotnet.ilcompiler\1.0.0-alpha-26216-01\build\findvcvarsall.bat" amd64" exited with code 1. [D:\Temp\hello\hello.csproj]
```
After this change, we get
```
C:\Users\michals\.nuget\packages\microsoft.dotnet.ilcompiler\1.0.0-alpha-26216-01\build\Microsoft.NETCore.Native.Windows.props(101,5): error : Platform linker not found. To fix this problem, download and install Visual Studio 2017 from http://visualstudio.com. Make sure to install the Desktop Development for C++ workload. [D:\Temp\hello\hello.csproj]
```
|
|
compilation (#5364)
Contributes to #5289
|
|
* Pass /LIBPATH to linker
Package [Microsoft.DotNet.ILCompiler v1.0.0-alpha-26207-01](https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.DotNet.ILCompiler/1.0.0-alpha-26207-01)
was failing to compile WebAPI app when using non-developer command
prompt on Windows, because Kernel32.lib and friends weren't get located.
Capturing those from vsvarsall environment in `findvsvarsall.bat` script
and passing it to link.exe fixes the error and compiles WebAPI app
successfully.
* Update docs to reflect the behavior
|
|
* Enable wasm building on OSX.
Upgrade libLLVM to 4.0.0 and LLVMSharp to 5.0.0
LLVM upgrade: Fix 'Use still stuck around after Def is destroyed' of the deleted basic blocks
Add wasm support in runtest.sh
Remove HelloWasm.csproj reference to .ilproj on non-windows OS because of dependency on ilasm
Fix LinkNative target to execute correct commands for Unix wasm builds.
Added support for building on Ubuntu 16.04.3
Update documentation on how to build WebAssembly.
|
|
|
|
And AdditionalNativeFramework to NativeFramework, as discussed in https://github.com/dotnet/corert/pull/5273#pullrequestreview-90536352.
|
|
* Pass required frameworks to the linker on macOS
The `CoreFoundation` and `Security` frameworks are required to link anything that includes `System.Security.Cryptography.Native.Apple.a`.
* Update WebApi instructions for macOS
|
|
When iterating on RD.XML changes we shouldn't have to delete all the intermediates to trigger a recompilation.
I took this as an opportunity to make `RdXmlFile` an item. The compiler supports multiple, and so should the project.
|
|
* Add diagnostic messages to the build targets
Two things:
* Running ILC takes a while but we don't print any information about it. Print a message.
* Invoking the publish from a clean command promt is something that will happen very often I assume. Make sure the failure message is more prescriptive.
We'll want to make these messages localizable at some point...
* Update Microsoft.NETCore.Native.Windows.props
* Attempt to add macOS/Linux handling
|
|
|
|
|
|
|
|
* Changes to hook up the portable runtime and bootstrapper. Includes implementing allocation using RhpNewFast as well as some floating point codegen fixes required to make the new code compile.
Removes usage of buggy dladdr API in WebAssembly, fixes order of conditional branch expressions, which fixes printing when C# optimizations are enabled, adds debug and release flags to emcc, updates WebAssembly documentation to reflect the new build flavor and linking steps. Adds thunks for RuntimeExport methods to fix linker errors for missing runtime exports.
|
|
As it stands we only produce a Windows ILCompiler package. This work implements building and publishing of OS-specific runtime packages and spins off ILCompiler as a meta-package, which can be referenced when adding to a project.
Working on this, a quirk in MSBuild behavior under .NET Core popped up - build artifacts (i.e. .targets and .props files) are imported for direct project package references, but not for runtime-specific packages, defined as dependencies in the meta-package. This doesn't seem to be the case in vanilla MSBuild.
The below is a serious hack to work around this - during runtime, we find the resolved runtime package reference and define the path to it on disk, from which all OS-specific components are loaded and run. The motivation behind the workaround was to keep the package as small as possible, particularly because of the large intersection of components between OS implementations.
All workarounds are marked as such and should be removed once Microsoft/msbuild#2807 is resolved.
There is some slowdown because of sequential resolution of targets, but not immediately noticeable and is unfortunately unavoidable - almost entirely avoided if CoreRT build targets are referenced directly (excluding MSBuild overhead).
|
|
|
|
* Fix issues building the runtime, corelib and type loader for WebAssembly
* Fix test infrastructure to allow running with the wasm flavor
|
|
|
|
* add bootstrapper for native libraries (#1285)
* overwrite main method when building library (#1285)
* add stub for native library startup method (#1285)
* Include nativelib switch for compiler
* suppress checking for entrypoint when -nativelib
* initialize runtime at start of reverse PInvoke, unix dlopen successful (#1285)
* don't run library initializers for Multi module build (#1285)
* update buildscript to build unix static library (#1285)
* update buildscript to build Windows static library (#1285)
* create and use NativeLibraryInitializerRootProvider (#1285)
* use "shared" linker arg on unix to build shared library (#1285)
* use system module to initialize NativeLibraryInitializerRootProvider (#1285)
* initialize runtime just before initializing the thread (#1285)
* move InitializeRuntime call to within TSF_Attached state check (#1285)
* use static struct constructor to set InitializeRuntime pointer (#1285)
* do not include main function in native library build (#1285)
* move runtime initialization check to thread init (#1285)
* use Thread* to determine whether to initialize runtime (#1285)
* handle race conditions when initializing runtime (#1285)
|
|
* Explicitly set SDK and Framework assemblies
* Add error checking to assembly item groups
|
|
Support for the dotnet publish command. Built on top of changes made by @nattress .
NuGet packages that target .NETCore specifically can be published safely, but most others targeting the .NETFramework cannot.
|
|
* Determinism test harness
Add a /determinism mode to runtest.cmd that will invoke ILC twice with different random determinism seeds. This causes graph expansion to be randomized based on seed (though deterministic for a given seed).
* Add Utf8String.CompareTo
Implementation taken from S.P.CoreLib. All the loop unrolling optimizations were excluded; we re-implement them if this function becomes a perf bottleneck.
* Define the mechanisms for determinism
To ensure deterministic output, all nodes that are emitted to the binary are sorted after compilation when retrieving the final marked nodes list. The overall approach is to sort nodes of the same type together (ie, all EETypeNodes come before NonGcStaticsNodes). Within nodes of the same type, a comparison function uses a CompilerComparer to compare the key identifying data of a node. For example, an EETypeNode is defined by a TypeDesc. The CompilerComparer provides a stable comparison function for comparing various type system primitives. Some nodes need to be emitted in an early and specific order for compiler correctness; this is provided by partitioning all sorted nodes into two phases: the first phase containined specifically ordered nodes, and a second phase for all other nodes whose ordering in the output binary doesn't matter.
Add SortableDependencyNode abstract class which provides the sortability layer on top of a DependencyNodeCore. Both ObjectNode and EmbeddedObjectNode derive from SortableDependencyNode to provide sortability across all nodes that are emitted to the output binary.
Introduce `ISortableSymbolNode` to provide sortability for nodes that are currently referred to in the compiler via the ISymbolNode interface. Such nodes are actually `ObjectNode` or `EmbeddedObjectNode` instances that we've lost type information for. Instances that implement `ISortableSymbolNode` redirect to the matching SortableDependencyNode methods.
Add `EmbeddedDataContainerNode` as a base class of `ArrayOfEmbeddedDataNode` to allow comparison of different instantiations.
Refactor the interface dispatch map index calculation so it's done when the dispatch map is emitted at the end of compilation. Previously it was done when the indirection cell in the dispatch map array got marked. This mechanism is incompatible with generating stable dispatch map indices. The arrays of embedded nodes now stabilize IDs as they emit their final data. This introduces an output ordering dependency - OptionalEETypeNodes must be emitted after the dispatch map since they encode dispatch map indices. Manually enforce this with C++ code generation, since it doesn't emit the real dispatch map structure and builds its own.
Modify InterfaceDispatchMapNode to use the type name in name mangling instead of an index into the dispatch map table.
Modify ObjectDumper to also amit a sha256 hash of each node's data. This dump is used to diff the map files and prove determinism.
* Fill out ordering functions for all nodes
Most of these are not very interesting. Here's the overall approach:
- Every different type of node needs a unique ClassCode. These were generated using Math.Random.
- The various metadata / native layout nodes plus arrays of EmbeddedObjectNodes get placed in the Ordered phase with specific ordering of each.
- All other nodes go in the Unordered phase
- To order nodes of the same type, the data that represents the key for the node in NodeFactory is compared. Ie, for an EEType, that would be its defining TypeDesc, whereas a FrozenStringNode is defined by the string it represents).
- The marked nodes list also contains raw DependencyNodeCore<T> nodes, which aren't emitted. Those are all shuffled after the emitted nodes and not sorted amongst themselves. That hasn't proven to be a problem with determinism and saves a bunch of hopefully unnecessary comparisons.
|
|
|
|
WebAssemblyCodegenCompilationBuilder
|
|
- Pick up latest .NET Core 2.0 CLI and buildtools
- Remove all project.json references and convert everything to msbuild projects
- Stick to vanilla .NET CLI project shape as much as possible. Minimize dependencies on buildtools special behaviors
|
|
The latest project templates do not have it, and it is only good for generating warnings like the following in the detailed build log:
Project file contains ToolsVersion="4.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="14.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
[tfs-changeset: 1662024]
|
|
|
|
|
|
* Move creation of `MetadataManager` to `CompilationBuilder`. We'll want
to expose more compilation options in respect to metadata generation in
the future (e.g. satellite assembly metadata), so this is a much better
place to have it.
* Add compilation switch that lets us pass a file name to generate the
log into.
* Enable metadata log generation when building the framework object
files. Diagnostic breadcrumbs are generally useful.
|
|
|
|
* Linux support for multi-module
* Alter build integration scripts to support different naming / tool invocations on Linux.
* Add GC / frame info for ELF to the same group as its associated method so it gets Comdat folded properly.
* Add -multimodule switch to runtest.sh to run tests against a shared pre-compiled framework library.
* Update ObjectWriter Nuget package which brings changes need to support Elf Comdat sections.
|
