From owner-freebsd-sparc64@FreeBSD.ORG Thu Feb 16 23:14:50 2006 Return-Path: X-Original-To: freebsd-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 04ACA16A42A for ; Thu, 16 Feb 2006 23:14:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id D645743D69 for ; Thu, 16 Feb 2006 23:14:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 9262840 for multiple; Thu, 16 Feb 2006 18:14:47 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k1GNEM5H086940; Thu, 16 Feb 2006 18:14:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marius Strobl Date: Thu, 16 Feb 2006 18:09:36 -0500 User-Agent: KMail/1.9.1 References: <200602131150.k1DBo6S1074438@freefall.freebsd.org> <20060214205432.38121641.antoine.brodin@laposte.net> <20060216134823.S53619@newtrinity.zeist.de> In-Reply-To: <20060216134823.S53619@newtrinity.zeist.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602161809.38389.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1291/Thu Feb 16 15:15:09 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-sparc64@freebsd.org, Antoine Brodin Subject: Re: sparc64/93226: DEBUG_LOCKS (really stack_save()) causes panics on sparc64 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: Thu, 16 Feb 2006 23:14:50 -0000 On Thursday 16 February 2006 07:48, Marius Strobl wrote: > On Tue, Feb 14, 2006 at 08:54:32PM +0100, Antoine Brodin wrote: > > Marius Strobl wrote: > > > On Mon, Feb 13, 2006 at 09:37:19PM +0100, Antoine Brodin wrote: > > > > John Baldwin wrote: > > > > > On Monday 13 February 2006 13:36, Antoine Brodin wrote: > > > > > > John Baldwin wrote: > > > > > > > If there are kernel functions before the assembly ones > > > > > > > (dependent on link order) then this would wrongly bail when it > > > > > > > hit those. I think you need to do what the ddb stack tracing > > > > > > > code does which is to lookup the symbol name and do a bcmp() on > > > > > > > the first 4 chars to recognize trapframes. > > > > > > > > > > > > I ran objdump -d on a sparc64 kernel and it looks like tl0_* and > > > > > > tl1_* are always at the beginning of the code, there is some kind > > > > > > of magic. > > > > > > > > > > magic aside, it would be best to use the same algorithm in both > > > > > places IMO. It would also be a lot more intuitive to other folks > > > > > later on. > > > > > > > > There are 2 reasons why I didn't use db_search_symbol() and > > > > db_symbol_values() : > > > > > > > > - first they aren't reentrant, they use a global variable > > > > db_last_symtab and they can panic if a thread sets db_last_symtab to > > > > 0 while another one is using it. I found this in my mail archive : > > > > %%% > > > > Stopped at X_db_symbol_values+0x18: cmpl $0,0xc(%eax) > > > > db> trace > > > > Tracing pid 34983 tid 100093 td 0xc2e9c640 > > > > X_db_symbol_values(0,c0738214,e84859f4,e84859c4,7c) at > > > > X_db_symbol_values+0x18 > > > > db_symbol_values(c0738214,e84859f4,0,c89d19c8,0) at > > > > db_symbol_values+0x40 %%% > > > > It can be fixed easily but I don't have the fix anymore. > > > > You can use linker_ddb_search_symbol() and linker_ddb_symbol_values() > > > > too that are safer. > > > > > > > > - the second reason is performance. if you replace > > > > CTRSTACK(KTR_LOCK, &stack, 0, 1); > > > > by > > > > CTRSTACK(KTR_LOCK, &stack, 0, 0); > > > > in kern_lock.c, i.e. if you print the symbol name in the ktr traces, > > > > you will notice that your box is extremely slow. (you type ls, you > > > > wait 4 or 5 seconds and you have the result) > > > > > > Can't we just use what's done in support.S and add two dummy symbols > > > to mark the begin and end of the asm functions in question? > > > > There's already a tl0_base symbol. You can add a tl0_end (or tl1_end ?) > > symbol between tl1_intr and fork_trampoline. > > Ok, how about the attached patch? It uses two pairs of dummy symbols > in exception.S to determine in stack_save() whether it was one of the > tl0_*() or tl1_*() asm functions; one pair for those in the .trap > section that is "magically" placed at the beginning of the .text > section via the linker script and the other pair for those in the > regular .text section. That way we don't rely on the location of > these functions in the kernel and don't have the performance penalty > of *search_symbol()/*symbol_values(). For consistency db_backtrace() > is changed to also use the new markers instead of bcmp()'ing with > the symbol names. Looks like a winner, thanks! -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org