Date: Fri, 17 Nov 2000 15:23:33 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert@primenet.com> Cc: nate@yogotech.com, chat@FreeBSD.org Subject: Re: Turning on debugging in GENERIC Message-ID: <XFMail.001117152333.jhb@FreeBSD.org> In-Reply-To: <200011172304.QAA05502@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-Nov-00 Terry Lambert wrote: >> To clarify at least one thing, the reason that I personally would >> like to have INVARIANTS and a few other options in the kernel are >> due to the fact that the new SMP code is not entirely stable, and >> can give some rather cryptic crashes and behaviors that are >> symptoms of other harder to find problems. Enabling extra sanity >> checks results in many of these root problems being found easier >> as a bug is spotted sooner before it heads off into the weeds and >> breaks something else. A panic telling you that you that >> chooseproc() returned NULL and you are trying to schedule the NULL >> proces is much more helpful than getting a panic later on after >> you have executed some unknown amount of random code before you >> get a trap 12 off in lala land. > > This is all solid engineering ground. I only had reservations > about "DIAGNOSTIC", with regards to it changing code paths. I > don't think that "DIAGNOSTIC" should be included. It won't be. I've had sufficient feedback on that. Instead I'll track down any INVARIANTS type code that is currently conditional on DIAGNOSTIC and have it depend on INVARIANTS instead. >> Now, as for snapshots, we do have a snapshot server >> (current.FreeBSD.org) that keeps roughly the last 3 months of >> snapshots. Boot floppies don't have room for all the debugging >> info, so boot floppy kernels won't have the extra debugging, >> however the kernel that boots after the system is installed will. > > My suggestion here was a bit more complex. Having symbols there > is not the same as having a -g compiled kernel with the ability to > do source exeamination of a crash dump, or even a crash report > with a program counter. > > My suggestion was to change the (perhaps snapshot-only, perhaps > not) build process to build kernel's -g. The process would be: > > 1) Build a -g kernel (kernel.debug) > 2) strip -d -o kernel.nodebug kernel.debug > 3) strip -o kernel kernel.nodebug > >#3 is what goes on the floppies; #2 is what gets installed. #1 > is a _new_ file that's added seperately to the FTP archive, so > that a developer could better analyse a crash dump or bug report. This is pretty much what will happen. All that needs to be added (and it is rather trivial and something I had thought of doing) is to install the kernel.debug that is built and stick it in / as kernel.debug and kernel.GENERIC.debug. > PS: Are the snapshot dates accurate source tree dates? They > would need to be, if you wanted to rebuild a particular snapshot > form the source tree, and get an identical image (except for > the file dates, of course)... Yes. Also, the snapshots are a full release, including source, so one could always grab the source tarballs from the snapshot, untar them, and compile a test kernel. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001117152333.jhb>