jasonmolenda wrote: I think @labath would point out that I'm doing an end-run around making a sufficient Mock Process capability, with memory and threads and symbols, to write unit tests. @medismailben would point out that we could write a Scripted Process python script that would ingest this same information and vend a Process, just as well as using the corefile container for the information. For that matter, a little gdb remote serial protocol stub written in python could present this same information as if it were a live process with threads, registers, and memory.
Because I already had several mach-o corefile creator tools (and needed a new one each time I needed to test another part of the mach-o corefile reader part of lldb), it seemed most natural to go that route, to me. The most important part for me is the simplicity of taking a real world debug problem situation, live or corefile, which may involve giant binaries/corefile and cannot be used in a test for size or confidentiality reasons, but we can extract the core bits of registers and memory that are sufficient to show the issue being fixed. We can't test issues dealing with debug info with this mechanism -- say something specific to firmware debugging that can't be replicated in a userland process -- but for a lot of memory-and-stack-and-register type bugs, I think this could be a handy tool. https://github.com/llvm/llvm-project/pull/153911 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
