Windows createdump support
Build a Windows version of createdump that uses MiniDumpWriteDump.
Launch that createdump from the runtime when the runtime abort because of an unhandled exception when the same environment variables as Linux are set.
Hook up the diagnostic server dump message on Windows.
Add CrashDumpAndTerminateProcess function that generates a dump if enabled and terminates
the process. Replaced varous TerminateProcess calls in the runtime with this new function.
Add resource/version info to createdump.exe
Added stack overflow and debug assert hooks before calls to RaiseFailFastException
* Create spanified and Rune-accepting overloads of CompareInfo APIs
* Remove much of the duplicated code throughout CompareInfo
* Remove "empty string" optimizations that were causing incorrect comparisons against weightless code points
* Improve error detection around some edge cases
The strip command we invoke was stripping even the information that
is necessary for the debugger to find the separate .dwarf files,
so these symbol files had to be loaded manually into lldb. With
this fix, lldb loads them automatically.
Interaction of `fgComputePreds` and `fgAddRefPred` could be quadratic in the
number of preds.
Usually the number of preds is small (1 or 2) but in some cases seen from
compiled regular expressions it could be in the thousands. On one such case
a single call to fgComputePreds was taking ~20% of jit time.
Since we build the pred list in sorted order we can take advantage of this
to avoid searching the list for potential duplicates in `fgAddRefPred` when
it is called from `fgComputePreds` -- the only possible duplicate entry is
at the end of the list.
This doesn't address perf of subsequent calls to `fgAddRefPred` but likely
those happen somewhat randomly and are unlikely to be as costly.
When signature calling convention has `CORINFO_CALLCONV_EXPLICITTHIS`
set `this` argument is explicitly included in the argument list.
The importer wasn't taking that into account and was trying to pop
an implicit `this`, which resulted in `BADCODE("stack underflow")`
from `impPopStack` and `System.InvalidProgramException`.
Fixes#35384
* Improve Array.Sort(T[]) performance
A variety of tweaks to improve `Array.Sort<T>(T[])` performance and address a regression left over from moving the array sorting implementation from native to managed. The two most impactful are using `Unsafe.*` in `PickPivotAndPartition` to avoid bounds checks and aggressive inlining on `SwapIfGreater`. A few other small improvements to codegen round it out.
I only made the unsafe changes in the `Sort<T>(T[])` implementation, and not in the more complicated implementations, such as for `Sort<T>(T[], Comparer<T>)` and `Sort<TKey, TValue>(TKey[], TValue[])`, but I did make some of the smaller changes for consistency across the file.
* Address PR feedback, and more tweaks
* Fix null reference handling in VSD stub for x86
The regression test that I've added recently to accompany a fix for null
reference handling in VSD stub for x64 is failing for x86. The problem
is that the null reference handling in VSD dispatch and resolve stubs
was broken in another way due to the x86 calling convention. When the
call went through a shuffle thunk that removes one stack argument due to
the shuffle, the manual unwinding in AdjustContextForVirtualStub was
getting an ESP that was off by one stack slot and exception handling
wasn't able to correctly unwind from that location to the caller.
This change fixes it by letting the AdjustContextForVirtualStub manually
unwind to the instruction after the call to the shuffle thunk / VSD stub
and updating the ESP according to the number of stack arguments of the
target method.
I have also modified the regression test. One change was to make a call
with multiple parameters to verify that the logic to get stack arguments
size is working correctly. Another change was to make sure that both
dispatch and resolve stub cases are tested.
* Replace MethodTable in the ResolveStub by size of stack args
This prevents issues in case the type represented by the MethodTable got
unloaded.
* Make the stack arguments size stuff Windows specific
On Unix x86, the stack is cleaned up by the caller, not the callee.
* Refactor get_time_stamp_ns
* Add place holder function for pc to make pc build pass
* Add missing header file
* Move all time functions to mono-time.c
* Make sampling_thread_running a global variable
* Pass void* to init, clean_up and get_time function to accormodate different clock ID types for different os, and move back profiler specific function
* Add static keyword for local helper function and fix a typo
* Change to platform-specific typedef approach
* Add missing header file for macOS
* Add missing header file for linux
* Change header file name
* Change header file name one more time
* Fix failures on macOS
* Update src/mono/mono/utils/mono-time.h
Co-Authored-By: Ryan Lucia <ryan@luciaonline.net>
Co-authored-by: Ryan Lucia <ryan@luciaonline.net>
`mini_method_get ()` doesn't guarantee that `method->signature` is set.
Fixes a problem in https://github.com/mono/mono/pull/19624
/cc @lewing
Co-authored-by: lewurm <lewurm@users.noreply.github.com>
The management of the handle that native runtime keeps to
AssemblyLoadContext has changed to fix a race recently, so I am updating
the doc according to the change.
When a new thread is attached to the VM, the debugger will add it to the
`thread_to_tls` hash table. When that thread detaches, it will be
removed. Once the thread is attached, if a client is debugging, the
client can use the `CMD_THREAD_GET_FRAME_INFO` command to ask for
details about that thread.
This is a possibility that the thread detaches before the
`CMD_THREAD_GET_FRAME_INFO` command is processed, so the thread may not
exist the the `thread_to_tls` hash table any more.
This is a race condition, but is a valid state, so instead of asserting,
the debugger agent should indicate to the client that the thread no
longer exists, using `ERR_UNLOADED`.
Now that we have pred lists before morph, we can move the throw helper
tail merge phase earlier in the phase list.
This has two benefits:
* we can now merge a few more cases, because morph can introduce unique
temps for otherwise identical calls;
* it saves some throughput, because we no longer need to morph duplicate
calls.
There is more opportunity here to reduce code size if we can find the right
heuristic in morph to decide if throw helpers should be called or tail-called,
though the overall benefit is small (~600 methods, ~2000k bytes). I left the
current heuristic in place as I couldn't come up with anything better.
Fixes#35135.
The assert in EEClass::Destroy is invalid after a change #1201 that has
removed ArrayTypeDesc. It was causing failures of a large portion of the
coreclr tests.
There were also three tests that were failing due to test
incompatibilities with unloadability, so I am marking them as such.