From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10188 invoked by alias); 31 Dec 2006 12:36:59 -0000 Received: (qmail 10180 invoked by uid 22791); 31 Dec 2006 12:36:59 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 31 Dec 2006 12:36:48 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id kBVCacXA005803; Sun, 31 Dec 2006 13:36:38 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id kBVCacgf020195; Sun, 31 Dec 2006 13:36:38 +0100 (CET) Date: Sun, 31 Dec 2006 12:36:00 -0000 Message-Id: <200612311236.kBVCacgf020195@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: <20061231022259.GB719@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 30 Dec 2006 21:22:59 -0500) Subject: Re: [commit] Unwinder for OpenBSD/sparc64 kernel trap frames References: <200612310128.kBV1SDvF008133@brahms.sibelius.xs4all.nl> <20061231022259.GB719@nevyn.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00399.txt.bz2 > Date: Sat, 30 Dec 2006 21:22:59 -0500 > From: Daniel Jacobowitz > > 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