[Lldb-commits] [PATCH] D88387: Create "skinny corefiles" for Mach-O with process save-core / reading
Greg Clayton via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Oct 7 22:16:50 PDT 2020
clayborg added a comment.
In D88387#2318495 <https://reviews.llvm.org/D88387#2318495>, @jasonmolenda wrote:
> Yeah, I'm not opposed to mutually exclusive options to process save-core to request a specific style of coredump to be created, whether it's a --core-style enum or a series of flags isn't important to me. Right now I only intend to add the two that are possible - a full coredump or a modified-memory (dirty memory) coredump, on macOS. Whether it's passed as an enum or bitflag I don't have a preference, although a bitflag makes it sound like there could be multiple of them selected, when that's not what I'd be envisioning here. (if we were doing a series of flags for the lldb API, it would make more sense if we had different types of memory that could be coredumped and you could set the flags for what you want included. stack, heap, shared memory, binary images, etc.)
I think eventually it would be nice to get to multiple of the flags, but we can start with full or dirty only is fine.
> I forgot to respond to your suggestion about the SB API Process::SaveCore. I'm a little reluctant to add anything there yet because we're going from one style of coredump to two right now, and I'm not sure if we're going to stay at 2 forever or if we're going to evolve this into a panoply of different coredump styles and I'm not confident enough about this to want to put it in API. But I'm not wedded to that position.
Sounds good, lets work this out first internally and then expose via the SB API when we are ready.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88387/new/
https://reviews.llvm.org/D88387
More information about the lldb-commits
mailing list