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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
