This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit] Fix OpenBSD/i386 and OpenBSD/amd64 kernel trapframe unwinders
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