After adding the "dirty memory only" coredump style, I've been wondering how small a corefile I could get by only saving stack memory. I took a little time today to find out. A normal macOS corefile is a couple of GB, a dirty-memory corefile is around 440kb for a test binary. A stack memory corefile is about 20kb for that test binary.
I added a new "type" key-value pair to the qMemoryRegionInfo packet, and add "stack" to stack memory regions. David added a "flags" k-v pair for MTE but that has a specially formatted string of MTE flags in it (space separated) so I didn't want to mix in with that. It's straightforward to detect different memory types on Darwin systems, but I haven't thought of anything useful I could do by writing out heap dirty memory only or something. Maybe someone will think of some interesting way to use the memory region types.
In the test case, I create a stack-memory-only corefile, then read it back into lldb and fetch some stack & heap objects. SBValue has the unfortunate behavior (IMO) that it doesn't surface memory read errors in any way - so you can ask for a summary or a value of an SBValue object that couldn't read anything, and it will return 0/empty-string. We need to surface memory read errors better in lldb in these cases, this is just one of the issues with that.
I'm not sure a stack-memory-only corefile is especially useful for real C++/ObjC/Swift programs where many objects live on the heap. One thing I've thought about is trying to get a very tiny corefile showing interesting unwind states for writing tests against.
clang-tidy: error: 'lldb/Utility/ConstString.h' file not found [clang-diagnostic-error]
not useful