Date: Thu, 18 Oct 2001 18:59:33 -0600 From: Nate Williams <nate@yogotech.com> To: Greg Lehey <grog@FreeBSD.org> Cc: Nate Williams <nate@yogotech.com>, Dag-Erling Smorgrav <des@ofug.org>, FreeBSD-arch@FreeBSD.org Subject: Re: /usr/src/sys/scripts? Message-ID: <15311.31477.44659.191811@nomad.yogotech.com> In-Reply-To: <20011019102425.G60412@wantadilla.lemis.com> References: <20011018101828.A88312@wantadilla.lemis.com> <xzpy9m9wgux.fsf@flood.ping.uio.no> <15311.9266.464139.798092@nomad.yogotech.com> <20011019101722.C60412@wantadilla.lemis.com> <15311.30927.305794.574364@nomad.yogotech.com> <20011019102425.G60412@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>>>> BSD/OS has a directory /usr/src/sys/scripts which contains macros for > >>>>> kernel debugging. I have a number of macros here that I've > >>>>> accumulated over time, and I'd like to commit them. I'd also like to > >>>>> modify config(8) to install a .gdbinit in the kernel build directory > >>>>> if debugging has been specified; the .gdbinit would load macros from > >>>>> ../../scripts in order to help with kernel debugging. > >>>> > >>>> Wouldn't /var/crash be the logical place for .gdbinit? > >>> > >>> Yes, and no. Yes because that's where it may be useful, and no because > >>> it's a place for crashdumps, not for analyzing crashdumps. > >> > >> I've been thinking about this, and I think I agree with DES. We have > >> a basic problem that there are two different ways to use gdb, for > >> crash dumps and for remote serial debugging. The .gdbinit you use is > >> different in each case. I think it would make sense to install a > >> serial debug .gdbinit in the kernel build directory, and a dump > >> analysis .gdbinit in /var/crash (if present). > >> > >>> Most folks will probably not analyze the crashdumps, or they will copy > >>> them off somewhere else so they can free up /var/crash for the next > >>> crashdump, so I'd say stick .gdbinit somewhere else. > >> > >> If you can move the dump, you can move the .gdbinit. At least > >> /var/crash is a standard place to look for it. > > > > Only if we make it a standard place. A better place would be > > /sys/scripts/gdbinit.crash. > > Why? That's not obvious to somebody analyzing the dump in /var/crash. > One more thing to look for, one more pathname to remember. The people debugging crash dumps can certainly remember the name of a file as easily as they can remember the commands to type in gdb. This is a specious argument. (And, we can easily document it in the same place we document how to get backtraces in the kernel.) For 95% of the users, they have no need for .gdbinit, but the folks that may have use for it would be the same folks who have a use for a .gdbinit for debugging kernels over serial consoles, over the network (Jonathan Lemon's is working on this), and for looking at different data structures. In other words, there is no 'One True' .gdbinit, so we can provide the users with a plethora of choices to use, depending on the type of error they are seeing. :) > >> I think it makes sense, though I'm not clear about when to move it > >> there. Maybe savecore can do it if it's not already there. > > > > It has nothing to do with crashdumps themselves, but it has everything > > to do with debugging crashdumps. Just because there is a casual > > relationship doesn't mean it's the best place for the file. > > That statement applies to the saved kernel file as well. /var/crash is necessary to save since there's no other place to save it that guarantees a one-to-one mapping for dumps. If you replace your /kernel, then there's no way for the person debugging the file to be able to get to it. '.gdbinit' is common for *all* kernels, otherwise it would have no use. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15311.31477.44659.191811>