mchoo7 wrote: > The correct way to get unwinds that cross this boundary are for the > fault-catcher routine in the kernel (written in assembly) to have `.cfi` > directives expressing where to find the saved register context via a > non-volatile (aka callee-preserved) register. Then the unwinds work cleanly > across the system call. You also see this (and it's more important) in kernel > faults / timer interrupts entirely within kernel land.
> But we've never had a Platform add an unwindplan for a specific function -- > basically doing the .cfi directives manually in lldb, instead of putting them > in the assembly file. CFI is ideal, but there are two issues to implement FreeBSD kernel trapframe unwinder using it: 1. Currently we don't have enough CFI information in kernel source code. So if we go the CFI way, kernel dumps generated from previous versions cannot be interpreted by LLDB's plugin. 2. Debugging FreeBSD kernel on i386 and arm32 cannot be done with CFI under the current status. When KGDB unwinds arm32 stack, it makes decision dynamically after observing the PSR register. This can be solved by splitting entry points for each targets, but I'm not sure if the FreeBSD devs are happy to accept it. For i386 implementing unwinding with CFI is impossible since it needs information outside the frame that CFI cannot handle. Now from my perspective (which doesn't represent all FreeBSD developers of course), I'm fine with doing CFI way. i386 support will be EOL-ed in Nov 2028 and arm32's user pool is too small that its support is already falling behind compared to other architectures. When I create PR related to this, I'll add you to reviewers Thank you for your suggestion:) https://github.com/llvm/llvm-project/pull/192184 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
