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

[juli mallett]

* Bill Paul <wpaul at FreeBSD.ORG> [ Date: 2004-01-20 ]
	[ w.r.t. 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 ]
> 
> [abuse of __FILE__ and __LINE__ in panic()]
>  
> > This was rejected in all reviews.  It gives less information than
> > grepping the sources, at some cost (grep at least gives correct line
> > numbers when the sources don't quite match the binary).
> > 
> > Please back this out.
> 
> I have to second this.
>  
> > >   Ideally a traceback should be printed too, any takers ?
> > 
> > This can be obtained by running a debugger on the panic dump.  Line
> > numbers and source file names can also be printed by the debugger
> > if the executable has at least line numbers in its debugging info.
> 
> That's fine for developers who always run their systems with crash
> dumps enabled and posess sufficient debugger fu to analyze them. What
> about ordinary users who encounter a kernel panic due to a trap
> and need to report it? It would save wear and tear on everyone's
> nerves (_ESPECIALLY_ mine) if they could just send in a traceback
> rather than developers being forced to do the usual "go back and
> do nm ${KERNEL} and tell us what you see" exchange.

I'd really like non-DDB and DDB kernels alike to print traceback
and a _compact_ register dump on panic/trap/etc.  Traceback code
is MD, and as such can be implemented as calls to a common routine.
AFAIK we do not have to worry about calls in and out of DDB for this
stuff.  For the few cases you do, for i.e. symbol information, that
can be conditionalized.  By compact register dump, I mean all relevant
registers (including control registers), side by side, in some fixed
width reliant way.  As in

	%eax	0		%ebx	37		%ecx	24444444

And so forth.

This is heavily bikesheddable, but these are things we should be
doing unconditionally, in the opinion of a lot of people, myself one
of the least important, probably.  And if someone tells me to "shut up
and code" I'd be willing to give a stab at it.  It should be fairly
straightforward, providing you get the abstractions + indirections right.

Thanx,
juli.
-- 
juli mallett. email: jmallett at freebsd.org; efnet: juli;