Create a createdump static library for single-file dump generation

[mikem8361]

A "createdump_static" lib is now built that is linked into the single-file host and in the future can be linked into a Native AOT host/app going forward. For single-file apps most of the same unhandled exception or crash dump generation code is the same (same env vars, most of all the PAL code is the same) except where createdump executable was execve, a callback invokes (set by the host) the static createdump lib entry point.

File full dumps are generated (which currently are very large under MacOS) but the user can put the DAC side-by-side with their app and the smaller heap or mini dumps can be generated. The SDK could give an option to publish the DAC SXS for a single-file app.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

A "createdump_static" lib is now built that is linked into the single-file host and in the future can be linked into a Native AOT host/app going forward. For single-file apps most of the same unhandled exception or crash dump generation code is the same (same env vars, most of all the PAL code is the same) except where createdump executable was execve, a callback invokes (set by the host) the static createdump lib entry point.

File full dumps are generated (which currently are very large under MacOS) but the user can put the DAC side-by-side with their app and the smaller heap or mini dumps can be generated. The SDK could give an option to publish the DAC SXS for a single-file app.

Author:	mikem8361
Assignees:	mikem8361
Labels:	area-Diagnostics-coreclr
Milestone:	-

[mikem8361]

/cc: @LakshanF

[mikem8361]

This change adds only 125KB to the singlefilehost on Linux x64.

[mikem8361]

Code review ping.

[tmds]

@mikem8361 does this add into the single file host the ability to create a dump?
Is there a way to request a running single file host to create a dump of itself?

[mikem8361]

It should end up working like regular app (with createdump/DAC side-by-side), where the Microsoft.Diagnostics.NETCore.Client WriteDump API can generate core dumps of the process. Calling the API on itself isn't well tested but should work I think.

[mikem8361]

@hoyosjs - ping.

[tmds]

It should end up working like regular app (with createdump/DAC side-by-side), where the Microsoft.Diagnostics.NETCore.Client WriteDump API can generate core dumps of the process. Calling the API on itself isn't well tested but should work I think.

It would be nice if on Unix the dump could be requested by sending a signal (like SIGQUIT) to the process without requiring additional libraries/tooling. Do you think it's worth opening an issue for?

Note that Mono has a thread dump feature via SIGQUIT:

runtime/src/mono/mono/mini/mini-posix.c

Lines 287 to 289 in aaa1de1

	MONO_SIG_HANDLER_FUNC (static, sigquit_signal_handler)
	{
	mono_threads_request_thread_dump ();

[mikem8361]

@tmds, enabling SIGQUIT to generate dumps would be a feature requiring an new issue. This is complicated by the fact the runtime handles SIGQUIT to do some cleanup.

[tommcdon]

Fixed #68676