jasonmolenda added a comment. Thanks for the feedback Pavel. Good point on piping the dirty pages list through the memory region command and adding tests for that. And good thoughts on different memory types that could be included in the corefile. I think we may revisit how the 'process save-core' command arguments work as we add more formats. We could do some pretty cool stuff here.
I'm not going to bite this off right now, but I was thinking about the fact that a "dirty memory only" corefile depends on having all the binaries on the system that the corefile was taken. Why can't you run lldb on a dirty memory corefile and create a full corefile from it, if it's on the same system with the same libraries? Also, with a full corefile, if we know the dirty-memory-page list, if a memory region corresponds to a binary (libc.so text for instance), why should we read the memory from the inferior at all? We can copy the pages of the binary into the memory buffer. On a Darwin system, the vast majority of a full corefile are system binaries that are unmodified; it would make a full coredump a lot faster to create. I don't think perf is the most important thing with a corefile, but just some thoughts I had while looking at this. 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
