Date: Wed, 24 Mar 2004 17:37:21 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: arch@FreeBSD.org Subject: Having thread->td_frame point to the most recent frame Message-ID: <20040325013721.GA1103@ns1.xcllnt.net>
next in thread | raw e-mail | index | archive | help
Gang, I'm revamping kernel debugging support and thread awareness is one of the features that I'm going to add (at least for remote gdb, but likely to ddb as well). It's the thread awareness that causes me to raise the following issue: When we enter the kernel, we set curthread->td_frame to the current frame only when we came from user mode. This obviously to make sure the frame remains valid across nested interrupts/traps. For debugging you really want the latest (most recent) frame so that when you switch to a particular thread to produce a backtrace, you have the right frame (=context). So naturally, you really want to have thread->td_frame point to the frame that corresponds to the current kernel entry, whether from userland or not. One way to deal with this is to link frames so that the frame of the most recent entry is pointed to by thread->td_frame and the frame of the previous kernel entry is pointed to by thread->td_frame->tf_prev (or NULL when there's no previous frame -- or whatever). Obviously, we need to restore the previous frame when we exit the kernel. Thus, on entry into the kernel we do something like: framep->tf_prev = curthread->td_frame; curthread->td_frame = framep; On exit from the kernel we roll back like: framep = curthread->td_frame; curthread->td_frame = framep->tf_prev Q1: Are there any corner cases I'm missing or would such a scheme work? Q2: What's impacted if and when a new field to struct trapframe is added? Q3: Are there better alternatives for solving the issue? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040325013721.GA1103>