From owner-cvs-src@FreeBSD.ORG Tue Jan 20 10:45:24 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 0A77016A4CF; Tue, 20 Jan 2004 10:45:24 -0800 (PST) Date: Tue, 20 Jan 2004 12:45:24 -0600 From: juli mallett To: Bill Paul Message-ID: <20040120184523.GA26124@FreeBSD.org> References: <20040120175334.W3279@gamplex.bde.org> <20040120182929.4573C16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040120182929.4573C16A4CF@hub.freebsd.org> User-Agent: Mutt/1.4.1i X-Negacore: Yes X-Authentication-Warning: localhost: juli pwned teh intarweb cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Bruce Evans cc: phk@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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 18:45:24 -0000 * Bill Paul [ 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@freebsd.org; efnet: juli;