jasonmolenda added a comment. 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 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88387/new/ https://reviews.llvm.org/D88387 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
