From owner-cvs-all@FreeBSD.ORG Tue Jan 20 22:26:46 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5783C16A4CE; Tue, 20 Jan 2004 22:26:46 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8563943D1D; Tue, 20 Jan 2004 22:26:44 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i0L6Qhug024751; Wed, 21 Jan 2004 17:26:43 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0L6Qffe011012; Wed, 21 Jan 2004 17:26:42 +1100 Date: Wed, 21 Jan 2004 17:26:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Don Lewis In-Reply-To: <200401210454.i0L4sA7E060634@gw.catspoiler.org> Message-ID: <20040121170450.K7572@gamplex.bde.org> References: <200401210454.i0L4sA7E060634@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: phk@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 swtch.s src/sys/kern kern_shutdown.c src/sys/sys systm.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 06:26:46 -0000 On Tue, 20 Jan 2004, Don Lewis wrote: > What about the case of macros like KASSERT() and the vnode lock > assertions? Won't they report the name and line number of the #define? Er, macros don't work like that. KASSERT() expands to a call to panic() (and other things) inline, so it gets the name and line number from the file that has the KASSERT(). The vnode lock assertions expand to calls to functions, so the line numbers are just for the functions that call panic(), if any, and are negatively useful (same as for trap()). The vnode lock assertions actually never call panic(). They optionally call Debugger(), and the control variable for this used to be misnamed vfs_badlock_panic, but the variable is now named vfs_badlock_ddb and Debugger() just calls printf() DDB is not configured (I thought that it paniced). The mutex macros expand __FILE__ and __LINE__ inline (only in some cases, mainly the INVARIANTS case), and then call functions; if there is a problem, then the functions call panic() with their caller's file and line; panic() prints their caller's file and line, and now also panic()'s caller's file and line. The vnode lock assertions could be expanded to pass around the file and line like the mutex macros do, but I think that is the wrong way to go. Backtraces give equivalents to the file and line for everything on the call stack, with no runtime costs and no source code costs except in the backtrace code. Bruce