Date: Wed, 21 Jan 2004 17:26:41 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Don Lewis <truckman@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 Message-ID: <20040121170450.K7572@gamplex.bde.org> In-Reply-To: <200401210454.i0L4sA7E060634@gw.catspoiler.org> References: <200401210454.i0L4sA7E060634@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040121170450.K7572>