| 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
|
|
* 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)
|
|
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]
|
|
|
|
[tfs-changeset: 1664997]
|
|
This change implements basic support for thread static fields. Most things
are already functional, performance could definitely be improved in the
future but it should be sufficient to get things off the ground.
This code passes CoreRT and Top200 CoreCLR tests on Windows. The
BasicThreading test in this change verifies that thread static fields work
for both non-generic and generic types in the single-threaded and
multi-thread environment (using Tasks).
One thing that does not work yet is multi-module compilation because the
driver creates a separate ReadyToRun helper for a type in every module
that accesses thread statics of the type. I am currently working on fixing
this.
The existing code has already implemented a good chuck of required
functionality so this simply builds on top of that.
Each module has a ThreadStatic region. Each entry in the region points to
an EEType that represents a GC map for the thread static fields of a given
type. The index of the entry in the region is the TLS index of the type.
The TypeManager indirection node of the module has been extended to
contain the index of the module in addition to a pointer to the type
manager (which is also used for initialization on first access).
The generated ReadyToRun helpers (that return thread static base for a
type) look like this:
__GetThreadStaticBase_System_Private_CoreLib_System_Threading_ManagedThreadId:
48 8D 0D BD E0 39 00 lea rcx,[__typemanager_indirection
(07FF70D68AD58h)] <= module information (type manager, module index)
BA 03 00 00 00 mov edx,3 <= TLS index of the type
E9 33 FB E4 FF jmp
System_Private_CoreLib_Internal_Runtime_ThreadStatics__GetThreadStaticBaseForType
(07FF70D13C7D8h)
|
|
to ProjectN. The nature of the changes in this changelist is very similar to the changes done in CoreCLR described in the linked PR:
1) This change synchronizes the ndp/FxCore/CoreRT/Native/gc and src/vm/gc directories of ProjectN and coreclr, respectively. There is one additional change present in this changelist that was not done to CoreCLR (and will need to be ported to CoreCLR), and that is the addition of IGCHeap::RegisterFrozenSegment and IGCHeap::UnregisterFrozenSegment to the interface. These functions are invoked from RedhawkGCInterface::RegisterFrozenSection and as such must be present on the interface. This is a very minor change that involved ensuring that Register/UnregisterFrozenSegment are defined for all builds (not just defined when FEATURE_BASICFREEZE is defined) and propagating the definition of those two functions to IGCHeap, instead of IGCHeapInternal where they resided on CoreCLR. Calling either of those two methods with FEATURE_BASICFREEZE not defined results in an assert.
2) Like the changes to the VM in CoreCLR, uses of GCHeap in CoreRT/Native/Runtime are redirected to the GCHeapUtilities class, which maintains the singular IGCHeap instance and provides a number of static methods used by the runtime to access and query the state of the heap. For most cases in Native/Runtime, this meant renaming uses of GCHeap to GCHeapUtilities. There is a notable exception to this in that GetMaxGeneration is turned into a virtual method call on IGCHeap on non-DAC code paths (see https://github.com/dotnet/coreclr/pull/6764#issuecomment-245462736 for details on why I chose to expose a virtual and non-virtual version of GetMaxGeneration)
3) This set of changes broke SOS GC heap dumping on CoreCLR when FEATURE_SVR_GC is defined, so this change contains a fix for that particular issue. As far as I know, FEATURE_SVR_GC is not defined on the ProjectN build, so this has no effect for now, but it will fix an issue that would be present if/when we enable Server GC. This particular fix is located in request.cpp.
There should be no surprises in this changelist except for portable.cpp, which declares a complete alloc_context struct out-of-line from the GC interface - this change updates the declared alloc_context struct to match the one exposed by the interface.
[tfs-changeset: 1627236]
|
|
- Port EnsureSufficientExecutionStack to Unix by switching it to the same implementation as what we use for CoreCLR. It is piggy backing on stackbounds that the runtime keeps track of.
- Add TryEnsureSufficientExecutionStack since it was added as public method for CoreCLR (see https://github.com/dotnet/coreclr/pull/7077/)
[tfs-changeset: 1626388]
|
|
[tfs-changeset: 1624932]
|
|
[tfs-changeset: 1622253]
|
|
- Use extern "C" names for methods called from asm helper to avoid dealing with name mangling for ports
- Move hooking up of the PInvoke tunnel to C++
- Change arm assembly code to follow same naming pattern as x86 and arm64
[tfs-changeset: 1609408]
|
|
- 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]
|
|
- Replace asm wrappers for GC helpers with regular PInvoke for better portability. There is an extra GC mode switch now but it should not matter because of these helpers are either expensive or rarely used.
- Remove asm code for RhpBulkWriteBarrier by switching to C++ implementation unconditionally (remove CORERT ifdef)
- Move error handling for RhHandleAlloc* to System.Private.CoreLib (remove CORERT ifdef)
- Add missing error handling for RhReRegisterForFinalize
- A few other minor fixes and cleanup
[tfs-changeset: 1596653]
|
|
This change replaces usages of the uint thread id by EEThreadId at
places where we use it for thread matching. It also adds new
PAL function GetPalThreadIdForLogging that returns a numeric thread
id for logging purposes if the target platform supports it.
The reason for this change is that in pthreads, thread id is an
opaque struct and numeric id existence is platform specific.
|
|
|
|
In implementation of the calling convention converter it has been discovered that we need to conservatively report the callee arguments to the GC in some cases.
This change implements a mechanism for conservative reporting (As discussed with SMosier)
- New mrt100_app api surface for initializing and disabling conservative reporting
- RuntimeAugment that supports using the new conservative reporting. It utilizes the extra call/fixed statement to set up for the correct reporting
- Actual mrt100_app changes to implement conservative reporting (See changes to gcrhenv.cpp)
[tfs-changeset: 1564327]
|
|
[tfs-changeset: 1561881]
|
|
[tfs-changeset: 1558329]
|
|
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.
|
|
|
|
|
