Re: [commit] Fix OpenBSD/i386 and OpenBSD/amd64 kernel trapframe unwinders

[Daniel Jacobowitz <drow@false.org>]

On Thu, Dec 22, 2005 at 04:20:07PM +0100, Mark Kettenis wrote:
> I've struggled with this for a while.  Apart from adding DWARF2 CFI to
> the kernel, there's no real alternative to matching function names.
> And DWARF2 doesn't allow me to terminate the backtrace at the user to
> kernel transition.

Yes it does - what do you think inspired my patches for an undefined
return address column? :-)  They were for Linux's KGDB.

Unless the OpenBSD kernel has a distressingly large number of entry
points, the same thing should work there.  It's only if you want to do
something besides stop at the boundary that things get really
complicated.

> Simply matching the function names is of course
> unacceptable, so I had to do something a bit more clever.  If you look
> at the sniffer for the unwinder, you see the following check:
> 
>   cs = frame_unwind_register_unsigned (next_frame, AMD64_CS_REGNUM);
>   if ((cs & I386_SEL_RPL) == I386_SEL_UPL)
>     return 0;
> 
> This checks the Requested Protection Level, which is stored in the
> lower two bits of %cs.  When executing in the kernel, the RPL is 0,
> for userland its 3.  So we can reliably check whether we're in the
> kernel or in userland.  And I only check the magic function names when
> the current frame is a kernel frame.  I guess I should add a comment
> in the code about that.

Aha, I missed that.  And we're OpenBSD targeted here, so if we're in
kernel mode, it's a reasonably safe assumption that we're in the
OpenBSD kernel.  I'd appreciate a clarifying comment.

> P.S. The new Xorg X11R6.9/X11R7.0 doesn't need any special patches
> anymore since they now use dlopen(3) to load modules.

Ooh, that's good news.  The Linux kernel module loader still does,
though - they've been talking about loading objects as shared libraries
for years, but I don't think it's going to happen soon.

-- 
Daniel Jacobowitz
CodeSourcery, LLC