| Age | Commit message (Collapse) | Author |
|---|
|
* Fix issues building the runtime, corelib and type loader for WebAssembly
* Fix test infrastructure to allow running with the wasm flavor
|
|
|
|
CoreRT is component of ProjectN (aka .NET Native for UWP), but our current defines do not reflect it because of CORERT is not defined in ProjectN builds. This creates confusion for folks outside the core runtime team, and conflicts with our documentation. For example, https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md says "CoreRT is the .NET Core runtime that is optimized for AOT scenarios, which .NET Native targets". It does not say "CoreRT is the .NET Core runtime optimized for AOT scenarios that uses RyuJIT backend" or anything like that.
- Before this change:
PROJECTN: defined in closed source ProjectN builds
CORERT: defined in open source CoreRT builds
CORECLR: defined in CoreCLR builds
- After this change:
PROJECTN: defined in closed source ProjectN builds (same)
CORERT: defined in both open source CoreRT builds and closed source ProjectN builds (different)
CORECLR: defined in CoreCLR builds (same)
[tfs-changeset: 1680901]
|
|
|
|
|
|
|
|
|
|
The class lib functions are already hooked up to code manager. However, there are cases where we look for class lib functions from EEtype, such as GetClasslibException on an eeype. This change attaches the class lib function array to every type manager and sets up a runtime helper to get to the class lib function GetRuntimeException from an EEtype.
[tfs-changeset: 1653592]
|
|
|
|
Handling of hardware exceptions had a hack to add +1 to the actual instruction IP. Windows x64 unwinder
is disassembling instructions at the IP passed in to detect method epilogs. If the bytes at IP + 1
happened to match the epilog pattern, the unwind is done as if we were in the middle of the epilog that
lead to spectacular crash.
This change is moving this adjustment to be done later for EH related things only, and not interfere
with stackwalking.
Fixes #2535
[tfs-changeset: 1645602]
|
|
The runtime is not compatible with jump stubs inserted by incremental linking, and it does not seem to be helping us much anyway.
Fixes #2348
|
|
This change implements code manager for Linux, context manipulation
and compiler changes necessary to enable exception handling.
All calls to libunwind are disabled for now on non-OSX though, since
our build system doesn't support specifying additional dynamic
libraries, which prevents us from using the libunwind.
Those pieces of code are under CAN_LINK_SHARED_LIBUNWIND ifdef so
that the ifdef can easily be located and removed after we add
the necessary support to the build system.
On OSX, the unwind functionality is part of the compiler support
libraries, so it works.
I have verified that everything works with the libunwind though
by manually invoking clang to link everything together and adding
the necessary libraries to its command line. The exception handling
test was passing with that.
|
|
Now that nutc generated code does not use them anymore, it is possible to cleanup RhExceptionHandling_ functions to not depend on GetReturnAddress intrinsic.
The binder generate wrappers around checked math helpers were calling RhExceptionHandling_ methods as well. I have changed these checked math helpers to be implemented in C# instead of using the wrappers. It makes them faster (e.g. checked multiplication is 20% faster on x86 now).
[tfs-changeset: 1613638]
|
|
- Reduce amount of assembly code in PInvoke helpers by moving all slow paths to C++
- Share code between the slow paths of assembly and portable helpers
- Improve performance of the portable helpers by making the access to current thread and the trap thread statics inlineable (e.g. the portable RhpReversePInvoke2 helper has only two extra instructions compared to what the hand-optimized assembly helper would have)
[tfs-changeset: 1605153]
|
|
This change modifies PAL_LIMITED_CONTEXT, StackFrameIterator and REGDISPLAY
structs and also all related code accessing registers that are not present
for Unix.
|
|
Fixing TODOs about collisions with the system assert.h header
[tfs-changeset: 1589045]
|
|
This change implements PalGetModuleFileName for Unix. Since the module name
passed to us is a utf-8 string, I have modified the signature of the function
to use TCHAR and then modified managed RhGetModuleFileName interop signature
to use byte* for Unix instead of char*. And I have also modified the called
of this function, the TryGetFullPathToApplicationModule, to perform
conversion of that to regular string.
|
|
|
|
Conflicts:
src/Native/Runtime/CachedInterfaceDispatch.cpp
|
|
The loop hijack worker routine is not honoring the contract that it should be. Namely, the runtime is not allowed to trash any registers in our worker (except r12 on ARM). The two big oversights were scratch FP registers and the flags registers.
I have also added a per-module map from loop index to target address (thus requiring all the shash.h includes). This primarily helps gcstress throughput because the loop indirection cell address calculation ends up being surprisingly lengthy. I considered the other obvious approach of "back-patching" the loop indirection cell in the gcstress case (normal loop hijacking does this, but under gcstress, we do not). However, I ended up preferring this because it could help GC suspension latency in normal operation.
[tfs-changeset: 1573401]
|
|
|
|
[tfs-changeset: 1572900]
|
|
Conflicts:
src/Common/src/Interop/Windows/mincore/Interop.MEMORY_BASIC_INFORMATION.cs
src/ILCompiler.Compiler/src/Compiler/PdbSymbolProvider.cs
src/Native/Bootstrap/platform.h
src/Native/Bootstrap/platform.windows.cpp
src/Native/gc/env/gcenv.windows.cpp
src/System.Private.CoreLib/src/Internal/Runtime/CompilerHelpers/ArrayMethodILHelpers.cs
tests/src/Simple/AsgAdd1/AsgAdd1.cs
|
|
|
|
|
|
[tfs-changeset: 1561881]
|
|
- Add lookup of all RyuJIT intrinsics
- Update manage implementations of the intrinsics to fit with what RyuJIT is capable of
- Make intrinsic expansions by the codegen to be optional by providing fallback paths
- Fix USE_PORTABLE_HELPERS to be defined for portable runtime only
These changes are under CORERT ifdefs as necessary to be reconciled with .NET Native for UWP later.
|
|
[tfs-changeset: 1558883]
|
|
- For now - until we have the proper multifile compilation in place, link the Runtime.Base .cs files into System.Private.CoreLib. The proper factoring of Runtime.Base is still guaranteed by building Runtime.Base as separate .dll.
- Remove many stubbed out helpers since the proper implementation is comming from Runtime.Base now.
- Fix CppCodeGen to deal with same RuntimeImport being used with different signatures (e.g. RpNewArray is imported under two different signatures in System.Private.CoreLib)
|
|
A recent investigation revealed a couple of bugs in our handling of fail fast.
1) If we hit our fallback path (EH.FailFast), we end up triggering an int 3, which is treated as a hardware exception in managed code, but we don't expect this exception code and we attempt to recursively FailFast. I've renamed this FallbackFailFast to make it more clear that we don't expect to hit this path in most cases. I've also made the implementation call into the C++ side and do an RhFailFast in there, which ultimately calls RaiseFailFastException, which shouldn't open up to infinite recursion.
2) The codepath that attempts to FailFast when an SEH exception is leaked out of a pinvoke was passing the OS dispatcher context's ControlPC as the bread crumb with which to find the class library that should perform the FailFast. Unfortunately, I'm so used to arm/amd64 SEH that I forgot that x86 SEH doesn't give you a good value for this. So on x86, we were getting null and failing to find the right class library FailFast to call, so we'd go down the fallback FailFast path when we shouldn't be. The fix here is to pull the PInvoke return address out of the PInvoke frame on the Thread. This is reliable and doesn't involve the OS, so it's goodness for all platforms.
[tfs-changeset: 1555875]
|
|
Enabled enough code to have a clean compilation on ARM64. Currently
nothing is really implemented and we either use the PORTABILITY_ASSERT
macro or a @TODO comment places that still need work.
|
|
CallingConvention.FastCall is not in .NET Core profile. I have changed it to Cdecl to match all other NativeCallable entrypoints in Runtime.Base.
[tfs-changeset: 1553473]
|
|
|
|
It been always set for years and there are no plans to build the runtime without it.
|
|
- Add CMake infrastructure for building assembly files
- Enable building of WriteBarriers.asm
- Add alternate unqualified entrypoints for canonical write barriers
- Remove compiler workaround
- Fix some stale comments
|
|
|
|
Provide specialized gcenv.h for CoreRT.
Some refactoring of related gcenv stuff.
Wire up finalizer code.
Add runtime-specific scanning code.
|
|
|
