| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Cleanup C++ glue code related to JIT helpers
|
|
The first issue here is another FailFast problem. Essentially, my last change to RhpPInvokeExceptionGuard--where I tried to account for x86 SEH being different from arm/amd64--failed to handle both modes in which it gets invoked properly. In both cases, we are handling the situation where we've experienced an SEH exception of some kind that hits our backstop handler in managed code. The issue occurs only when we didn't find the exception IP to be in managed code. Usually this means that the exception originated form native code, but this is not true if we, for example, have a call indirect through a bad pointer. The bad pointer is the exception IP in this case and if the caller was managed, we'll be in cooperative mode. In this case, it doesn't make sense to use the current thread's "pinvoke callsite return address". So, for the case where we're in cooperative mode, I've put it back to using the dispatcher context ControlPc on amd64/arm and switched to using the EstablisherFrame on x86. The handler address in the exception registration record is a managed code stub address, so I also had to adjust FindModuleRespectingReturnAddressHijacks to consider all addresses when attempting to find the managed module.
The second issue is a long-standing problem with filter invocation. Preserved registers should not be seeded to the filter and they should most definitely not be restored back to the REGDISPLAY when the filter is done. This is because filter invocation happens during the first pass and, as such, the stackwalker resets its state when it passes over the filter invoke. This means that the REGDISPLAY at the throw site is the 'live' location of any GC references in preserved registers -- i.e. the REGDISPLAY gets updated during GC (not the new stack locations downstream of the filter). So having the filter invocation code trample on the REGDISPLAY values when it's done has the effect of putting back stale values, thus creating a GC hole.
[tfs-changeset: 1561874]
|
|
- NUTC respects NativeCallable exports in public types only for some reason
- Conditionally disable CoreRT specific workaround with CMake dependency
[tfs-changeset: 1558734]
|
|
- 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)
|
|
[tfs-changeset: 1556987]
|
|
Populate EEType Optional Fields
|
|
Add rare flags, value type field padding, nullable type value offset.
Add ICastable method slots - untested since code using interfaces will not compile yet.
DispatchMap remains, which we need interface support for first.
Place all EEType enums for flags / fields into a single source file, EEType.Constants.cs
|
|
Fix catches around uplevel callbacks
|
|
This has been a latent issue that we've been working around for a
while now. The runtime shouldn't allow exceptions leaking out of
callbacks to the class library code to be dispatched across it.
The problem, though, is that the class library exceptions are in
one type space and the typed catch clauses are in another. I had
hoped to use filters to fix this, but Roslyn doesn't implement
them without the type check against System.Object (even if there's
no source reason for the type check). However, I realized that I
could simply fix the runtime exception dispatch to be more
permissible. It now permits catch ([runtime]System.Object) to
catch all exceptions, even those from foreign type spaces.
The workarounds have been in the class library-implemented
callbacks themselves where they have to put their own try/catch
clauses, but I always felt uneasy about not having a backstop in
the runtime to enforce this invariant.
I also ran across an unnecessary try/catch/rethrow that is from the olden days, so I removed it.
|
|
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]
|
|
[tfs-changeset: 1555333]
|
|
Fill out the fixed portion of the EEType data structure as expected by the runtime along with most of the variable pieces that follow.
Correct the code-gen's calculation of where VTable entries start in the EEType.
Add type-system support for asking if a type has a finalizer.
Move EEType Flags and Kinds enums to the Common folder and consume them from the compiler and runtime.
Transpose the new Type System's Category to a CorElementType for primitives / enum underlying types.
Remove HasFinalizer assert in RhNewObject
The following pieces are incomplete:
Optional fields side data structure
Interface dispatch map pointers
Type variance
Sealed virtual slots blob
Generic Type Def EETypes
|
|
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]
|
|
|
|
|
|
|
|
|
|
I discovered that when Runtime.Base is built without optimizations, we get a compiler-introduced temp that is alive across the outer loop wait operation which contains the first finalizable object from the last finalizer pass. This keeps the finalizable object alive for an arbitrarily long time and can be observed as unexpected behavior of handles with WeakLong semantics. My fix is to quarantine the handling of finalizable object refs to another [NoInlining] method to ensure that all of the object refs are off the stack when we're waiting on more finalizer work.
[tfs-changeset: 1551763]
|
|
- Add -systemmodule command line option that allows specification of the system module
- Root RuntimeExport methods for compilation
- Change the static constructor helpers to be looked up lazily in ReadyToRunHelperNode
- Fix up a few places in Runtime.Base that used to need static constructors
|
|
|
|
It been always set for years and there are no plans to build the runtime without it.
|
|
- Most of the .csproj file plumbing is copied from System.Private.CoreLib.dll
- Runtime.Base.dll build depends on AsmOffsets.h run through C++ preprocessor produced during CMake step of the build
|
|
|
