From owner-freebsd-arch@FreeBSD.ORG Fri Jun 10 21:32:58 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9985616A435 for ; Fri, 10 Jun 2005 21:32:57 +0000 (GMT) (envelope-from antoine@madhouse.dreadbsd.org) Received: from barton.dreadbsd.org (madhouse.dreadbsd.org [82.67.196.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2505D43D4C for ; Fri, 10 Jun 2005 21:32:56 +0000 (GMT) (envelope-from antoine@madhouse.dreadbsd.org) Received: from barton.dreadbsd.org (localhost [127.0.0.1]) by barton.dreadbsd.org (8.13.4/8.13.1) with ESMTP id j5ALWtaH095470; Fri, 10 Jun 2005 23:32:55 +0200 (CEST) (envelope-from antoine@madhouse.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id j5ALWsq5095469; Fri, 10 Jun 2005 23:32:54 +0200 (CEST) (envelope-from antoine) Date: Fri, 10 Jun 2005 23:32:54 +0200 From: Antoine Brodin To: "Poul-Henning Kamp" Message-Id: <20050610233254.44880290.antoine.brodin@laposte.net> In-Reply-To: <9261.1118346707@critter.freebsd.dk> References: <20050608221829.75c2de12.antoine.brodin@laposte.net> <9261.1118346707@critter.freebsd.dk> X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: RFC: Stack saving/tracing functionality. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 21:33:00 -0000 "Poul-Henning Kamp" wrote: > In message <20050608221829.75c2de12.antoine.brodin@laposte.net>, Antoine Brodin writes: > >Hi, > > > > > >With Jeff@'s help, I implemented stack saving/tracing functionality. > > Thankyou! > > >Another question: Since the stack saving/tracing functionality depends > >on ddb, should kern/subr_stack.c be moved to ddb/stack.c and > >sys/stack.h to ddb/stack.h? > > No. > > This code should be compiled in as standard so that any panic prints > a stacktrace on the console, also for non-KDB kernels. I put the MD code in //db_trace.c to avoid the duplication of some structure declarations like i386_frame, or the definition of the INKERNEL macro. Should I move these to something like /include/frame.h and put stack_save in its own file (this function is around 20 lines per arch) ? > A sysctl to enable grepping a backtrace from core-dumping processes > would be wonderful as well. It isn't possible to backtrace processes while they're in userland yet, and I'm not sure it would be safe (one could corrupt its own stack to try to confuse the kernel) and useful (gdb handles core dumps very well). But you can grab the end of life of the process in the kernel like: %%% #0 0xc04d712c at sigexit+0xfc #1 0xc04d6d9c at postsig+0x19c #2 0xc04f8fc8 at ast+0x4d8 #3 0xc061726d at doreti_ast+0x17 %%% I don't know if this is what you were looking for ? An updated patch with a correction in the alpha case is at: http://bsd.miki.eu.org/~antoine/stack/stack-06-10.diff Cheers, Antoine