From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 19:31:04 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED8616A41F; Sat, 20 Aug 2005 19:31:04 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10FC243D45; Sat, 20 Aug 2005 19:31:03 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7KJV2jb048915; Sat, 20 Aug 2005 12:31:02 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050820190957.GA66426@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> <20050820190957.GA66426@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 20 Aug 2005 12:31:02 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2005 19:31:04 -0000 On Aug 20, 2005, at 12:09 PM, Kris Kennaway wrote: >> What exactly is unreliable about backtraces in kgdb? >> > > Wih gdb53 I see the following: *snip* > #5 0x00000000c018d200 in kdb_trap (type=107, code=0, > tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > #6 0x00000000c02f6b44 in trap (tf=0x16e9a4630) at /usr/src.6/sys/ > sparc64/sparc64/trap.c:307 > #7 0x00000000c018cddc in kdb_enter (msg=0x0) at /usr/src.6/sys/ > kern/subr_kdb.c:267 > #8 0x00000000c018cdd4 in kdb_enter (msg=0xc03a2650 "panic") at / > usr/src.6/sys/kern/subr_kdb.c:267 > #9 0x00000000c016e144 in panic (fmt=0xc03c4130 "uma_small_alloc: > free page still has mappings!") > at /usr/src.6/sys/kern/kern_shutdown.c:537 *snip* > While the kgdb output is useless: *snip* > #5 0x00000000c018d208 in kdb_trap (type=107, code=0, > tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 > #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ > sparc64/sparc64/trap.c:307 > #7 0x00000000c0048fe0 in tl1_trap () > #8 0x00000000c0048fe0 in tl1_trap () > Previous frame identical to this frame (corrupt stack?) *snip* I see. As I said, kgdb cannot yet unwind across trapframes. Other than that the backtrace seems to be reliable. Not being able to unwind across backtraces is not particular to sparc64. kgdb cannot do that on any platforms. Some platforms, i386 in particular, are lucky in that kgdb is able to get out of the woods and pick up the trail after being lost for a handful of frames. This is due to the way backtraces work on those platforms. As for the resolution: I've been working on a new import of gdb, which allows us to register frame sniffers to handle this, but gdb has changed internally in such a way that our threading support cannot be compiled-in. This requires porting, which I don't want to do because it needs to be rewritten to support all platforms and merged into gdb. I don't see a point in fixing backtraces at the cost of the partial threading support we have now. In other words: it requires too much work for me to embark on it right now. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net