Re: [commit] Unwinder for OpenBSD/sparc64 kernel trap frames

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Sat, 30 Dec 2006 21:22:59 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sun, Dec 31, 2006 at 02:28:13AM +0100, Mark Kettenis wrote:
> > +  find_pc_partial_function (frame_pc_unwind (next_frame), &name, NULL, NULL);
> > +  if (name && strcmp (name, "Lslowtrap_reenter") == 0)
> > +    return &sparc64obsd_trapframe_unwind;
> 
> Does this really belong in GDB?  I ask because we've resisted adding
> similar things for other targets before - at least I have for Linux
> and for Xfree86, but maybe I should have been more accepting.

Heh, I believe you raised the same question when I added the same code
to i386 and amd64.  At that time I believe I convinced you that this
was acceptable.  This is not very invasive and nicely contained in
*BSD-specific files.  And the layout of kernel trapframes is pretty
stable.

GDB has been shipping with *BSD kernel debugging support for ages,
although it probably was almost completely broken until I cleaned
things up and replaced it with the kvm target a while ago.

I have looked into adding the XFree86 support too, but that was much
more invasive (because weirdness in their "dynamic linker"
implementation and problems with our shared library framework).  And
these days on OpenBSD, XOrg uses the normal ld.so to load modules.

Adding Linux kernel debugging support is much harder.  The rate of
change is much higher, there are kernel modules (which have a slightly
odd format).  And of course Linux doesn't have kernel core dumps, so
it would only be useful to debug a live kernel.

> Anyway, I have some thoughts on how to extend the unwind mechanism so
> that the OpenBSD kernel could ship a script that knew how to unwind its
> trap frames.

Did you really mean to say OpenBSD here?

Mark