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

[Bruce Evans]

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