mchoo7 wrote: > Thanks, this helped me clear up a big point of confusion for me (and those > manual pages are great btw). Is there anywhere that documents LLDB commands > for similar things? If the feature is not mature enough to put in the FreeBSD > manual then I think it would be fine to have a page on the LLDB site instead. > For example I have one that collects all the important trivia for AArch64 > Linux (https://lldb.llvm.org/use/aarch64-linux.html).
I'm planning to update it once my LLDB works are completed. But before that I need to write LLDB version of debugging script for kernel debugging (e.g. acttrace). > I wonder if this setting should only apply to /dev/mem, and writes should > never be allowed for offline crash dump debugging. > > The average user of userspace debugging would not expect to be able to write > to memory read from a core. Since we read the file from disk, I'm not sure it > could work without significant effort. > > Perhaps there is a use case for doing so, but I'd need to see that either > it's allowed by the other kernel debuggers, or that you're going to implement > it, and how you will do that. > > There is a blocker for what I'm suggesting though. If the FreeBSDKernelCore > cannot tell whether it's reading from /dev/mem, or from a crash dump (or the > code to do so would be unwieldy) then we cannot do this. I suspect writes in > a crash dump session would fail anyway, so we could rely on users to quickly > realise why that's the case. > > Can you show me what kgdb allows, if anything, and what happens in lldb if > you write during a crash dump session? Memory write is done through [`kvm_write(3)`](https://man.freebsd.org/cgi/man.cgi?query=kvm_write&apropos=0&sektion=0&manpath=FreeBSD+15.0-RELEASE+and+Ports&format=html) which states "The kvm_read(), kvm_read2(), and kvm_write() functions are used to read and write kernel virtual memory (or a crash dump file)". So it works with crash dumps as well. However this will be problematic once I start working on making this plugin cross-platform. But it's a future problem and the current implementation is closer to KGDB which has been working for decades. https://github.com/llvm/llvm-project/pull/183553 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
