| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* Remove dead code related to copy-constructors and intercept stubs
* PR Feedback.
|
|
|
|
* Remove more MDA support code
* PR Feedback
|
|
* First pass at adding winrt host entry-point.
* There's no way to specify HResult-swapping on a function called via hosted-interop so just return the HResult instead.
* Use the WindowsRuntimeMarshal class to create the activation factory and initialize it.
* Implement loading the dependent assemblies of a WinRT assembly into an isolated load context.
* PR Feedback.
* Fail to get the activation factory if the found type is not a managed type exported from a winmd.
* Rearrange parameters based on PR feedback.
* Remove unneeded include.
* Make ActivationFactoryLoader internal.
* Fix null-ref in WinRT-dependent-assembly loading
* Remove extraneous "System."
|
|
|
|
|
|
|
|
* Remove CallNeedsHostHook() API
* Remove IsHostHookEnabled() API and with it related dead code
* Remove code enabling host hooks (i.e. COMPlus_GenerateStubForHost)
Remove function declarations for creating host hooks
Update comments
|
|
* Move Decimal to shared
* Remove DecimalCanonicalize{Internal}
|
|
|
|
When _WIN64 is defined vm relies on the secret arg being
shifted left and orred with #1.
Revert part of changes from #17659 to fix dotnet/corefx#29266
Fix arm64 to match amd64
Simplify dllimport.cpp
|
|
|
|
https://github.com/dotnet/coreclr/commit/16fc3005c085212f6e700a0df8ff7f36c1ea535b
The PR was trying to fix an incorrect test , we should be passing
in !fForWinRT.See https://github.com/dotnet/coreclr/issues/13460#issuecomment-324456870
for more info.
|
|
|
|
|
|
Fixes #11611. The old hand generated assembly path did not work well for structs passed by reference.
|
|
(#11194)
|
|
For profiling purpose it only cares about condemned ranges; for byref
validation it cares about any object on the heap.
|
|
* Forbid inclusion of gcscan.h from VM and DAC directories
* Address code review feedback - hoist IsGCHeapInitialized check to an assert, since the heap should definitely be initialized if we are validating objects that ostensibly came from it
|
|
* Remove CLRIoCompletionHosted as it always returns false.
* Remove CLRSyncHosted as it always returns false.
* Remove CLRMemoryHosted as it always returns false.
* Remove CLRTaskHosted as it always returns false.
* Remove CLRAssemblyHosted, CLRGCHosted,and CLRSecurityHosted.
They are not called.
* Remove IsThreadPoolHosted as it always returns false.
* Remove EnterRuntime and LeaveRuntime, as they do nothing.
* Add back calls to RevertIfImpersonated and GCX_PREEMP.
I accidentally deleted the call to RevertIfImpersonated instead of just
removing an extra parameter.
When I removed the HR_LEAVE_RUNTIME_HOLDER macro from windowsruntime.h,
I not only removed a LeaveRuntimeHolder but also a GCX_PREEMP. So I added
it back. The holder and GCX_PREEMP where only inserted when the
FEATURE_LEAVE_RUNTIME_HOLDER macro was defined. Since it is always defined,
I removed it. Also as I understand it, you would always want to have a
GCX_PREEMP before calling into the Windows API as not to block the GC,
so I'm not sure why you would want to disable it.
|
|
|
|
|
|
|
|
modifying the VM to utilize this interface.
Introduce an interface separating the GC and the rest of the VM
Remove static members of both IGCHeap and IGCHeapInternal and move the management of the singular GC heap to the VM.
Rename uses of IGCHeap in the VM to GCHeapHolder, as well as other misc. renames throughout the VM and GC.
Split each interface function into categories, document them, use consistent formatting across the interface
Undo some accidental find/replace collateral damage
Remove all ifdefs from the GC interface
Deduplicate function declarations between IGCHeap and IGCHeapInternal, expose AllocAlign8 through the interface and the reference to alloc_context to repair the ARM build
Paper cut: false -> nullptr
Repair the ARM and x86 builds
Rename GCHeapHolder -> GCHeapUtilities and address documentation feedback
Rebase against master
Rename gcholder.h/cpp -> gcheaputilities.h/cpp
Fix an uninitialized field on alloc_context causing test failures on clang
Rename the include guard for gcheaputilities.h
Un-breaks SOS by making the following changes:
1) Instructs the DAC to look for IGCHeap::gcHeapType by name,
instead of assuming that it exists near g_pGCHeap,
2) Eliminate all virtual calls on IGCHeap in the DAC, since we cannot
dispatch on an object in another process,
3) Because of 2, expose the number of generations past the GC interface
using a static variable on IGCHeap that the DAC can read directly.
repair the Windows build
|
|
ensures that these fcall has a unique code address. (#6776)
|
|
|
|
This change fixes StubHelpers::ProcessByrefValidationList so that it doesn't throw.
While there was a EX_TRY / EX_CATCH, the catch handler calls FormatValidationMessage
to format the message before aborting the process and that function can throw.
The fix is to wrap the inside of the EX_CATCH in one more EX_TRY / EX_CATCH and
abort the process without message if there is an exception in the FormatValidationMessage.
|
|
_TARGET_AMD64_ whereas at other places (like NDirectStubLinker::DoNDirect & InlinedCallFrame::HasFunction ) related code is under _WIN64. Make the code in GetDelegateTarget to be in sync with other functions and remove ifdef _TARGET_ADM64_. Without this change for arm64 InlinedCallFrame::m_datum stores unmanaged target pointer but StackWalker assumes it to be a NDirectMethodDesc and tries to dereference it and crashes.
|
|
I've removed blocks with PAL_TRY that were under CATCH_GC. I also had to
fix contract problem in GCToEEInterface::GcStartWork that was marked as
THROWS due to StubHelpers::ProcessByrefValidationList being marked as
THROWS, but the StubHelpers::ProcessByrefValidationList in fact doesn't
throw since it has body wrapped in EX_TRY / EX_CATCH.
This also fixes a problem that started to appear after my previous exceptions
fix change.
|
|
|
|
|
|
(Interop\WinRT\Exception\ManagedClientNativeServer\ExceptionTest.csproj).
The test checks that the HResult 0x8000000e maps to a System.InvalidOperationException.
What was happening: We returned a System.COMException with the message "A method was called at an unexpected time." (we're just constructing an exception based on an HR message).
What should be happening: We return a System.InvalidOperationException (i.e. we check against the exceptionKind maps for a specific HResult to map to an exception).
The point of failure is in the creation of the EEMessageException. When calling GetKindFromHR(...) we were inverting the boolean that uses the WinRT mappings.
Removing that inversion allows us to check the WinRT Exception Maps for exceptions. When I made this change, we correctly return the correct Exception.
Test coverage: I ran a full DDR, and the whole TOF (both against my build and against the newest build). All passed successfully (i.e. no additional failures).
[tfs-changeset: 1514327]
|
|
[tfs-changeset: 1444911]
|
|
There isn't always a way to know the system function has failed without checking last error, in particular on Unix. Moreover, CLR does not guarantee that the last error is preserved while the managed code is running so this issue cannot be worked around calling SetLastError.
This change adds clearing of last error for P/Invokes with SetLastError=true. The cost of doing so is negligible, it makes error handling for P/Invokes of the above system functions possible, and all the other P/Invokes more robust.
|
|
[tfs-changeset: 1407945]
|
