| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
In multi-module mode, if one obj file defines an EEType as necessary and
another defines it as constructed, they get arbitrarily Comdat folded.
If the incomplete EEType is chosen, we see problems with VTable
dispatch, GC AVs (due to lack of a GC desc). In multi-module mode, if a
type is shareable (a concrete generic instantiation, or a parameterized
type such as `String[]`) upgrade requests for the EETypeNode to
ConstructedEETypeNode.
This causes an increase in Framework.lib from 111MB to 121MB due to
rooting more full types.
When running CoreCLR tests in multi-module mode, produce the shared framework library first and then prevent each test from generating it. I found that sometimes MSBuild gets confused and thinks it needs to re-generate the lib (despite the inputs and outputs being properly specified) so this makes sure we don't have multiple tests trying to produce the same set of files.
|
|
* Allows runtest.cmd /multimodule /coreclr
* Modify build integration targets to allow for tests with multiple
assemblies. We have two set of assembly inputs to ILC: @(ManagedLibrary)
which despite being an Item contains the main managed assembly to use as
the template name for the response file and output object file base
name. @(IlcCompileInput) is the list of assemblies that are inputs to
Ilc. This change allows us to compile all the app assemblies into a
single object file.
* Specify the inputs / outputs to the MSBuild task that builds the
framework assembly obj files. This removes a page of spam per test when
MSBuild skips over the already-built obj files.
* Currently 12 tests fail due to some EH issue that needs investigating.
|
|
* Consuming Microsoft.NETCore.Native package, which brings in libSystem.Globalization.Native.a
Replacing the dummy globalization implementation for unix with the actual one
|
|
* Enable multi-module on Windows
Enable multi-module compilation for tests in CI through a new switch:
`runtest.cmd /multimodule`. This will compile the framework assemblies
into a single Framework.lib that tests are linked against.
* Adjust several dependency nodes in the compiler to tidy up sharing of
nodes / naming for uniqueness.
* Add handling in ObjectWriter for compiler generated types and their
methods to force sharing.
* Ifdef out runtime imports for StdCall which are implemented in
Native.Interop, a library that hasn't been ported to CoreRT yet.
* Remove metadata generation for type args to an instantiation. This was
breaking type unification because we were treating type args as type
defs, even when they are present in another module and we weren't
emitting the actual EEType, causing a null type handle at runtime.
* Alter build integration MSBuild authoring to produce the framework lib
in multi-module builds on demand. By default, the lib is emitted in the
app binary folder. For test runs there are overrides to control where
the framework objs and lib are placed so they can be shared
(`FrameworkLibPath` and `FrameworkObjPath`).
* Alter test harness to take `/multimodule` switch which links all
Ryujit applicable tests against Framework.lib.
* CR Feedback
* Remove TypeSystem.Ecma reference and use IAssemblyDesc instead
* Move check for CompilerGeneratedType to ObjectWriter and check the
module against the generated assembly when determining shareability
* Always generate static bases for library modules
Fixes issue https://github.com/dotnet/corert/issues/2568 where static
fields that aren't referenced anywhere in a module compiled as a library
won't get their static base generated in the image. This causes link
failures when an app is built against the library.
Added a test that is compiled as two separate modules and linked
together.
* CR Feedback II
Fix release Windows multi-module compilation. The __managed_code_a and _managed_code_z bookends were being collapsed into one by the linker. We then told the code manager there were 0 bytes of managed code and EH broke. Fixed to give each book-end symbol a unique value so the linker won't fold them.
|
|
After #2403 got fixed there's nothing preventing us from finally
implementing this.
Includes piping in the driver EXE, Compilation and RyuJIT compilation,
and build integration.
Fixes #696. Fixes #383.
|
|
* Update CoreRT doc to include how to debug ILC using VSCode in non-windows
* Automate some of the tasks and check in vscode .json files
* Simplify instructions
* Explains the magic and added a bit more coding annotations to make it looks better
* Change ILCompiler.csproj to output ILC.dll directly to be VS-code friendly
|
|
Update default clang version to 3.9 and require xcode 8
|
|
This change updates the default clang version used to build CoreRT to the
latest stable version 3.9. It also removes the version 3.5 from the supported
ones. The 3.5 has a bug preventing us from using thread_local C++ feature.
Due to the same reason, the minimum supported xcode version on OSX is 8, so
the prerequisities document is updated accordingly.
|
|
- Use NameMangler.GetMangledTypeName directly to get the EEType name
- Delete filtering of IsPointer and IsByRef during type emission since it works fine now
- Add bigobj compiler switch to allow large auto generated .cpp files
Fix #2486
|
|
|
|
This is the first iteration of PInvoke change which ensures right
infrastructure is in place for future PInvoke changes. It doesn't
add any new PInvoke features, but makes sure all the existing ones
are working. I have also added a testcase.
|
