tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: debug sets?



David Young <dyoung%pobox.com@localhost> wrote:

> It's handy to build NetBSD with MKDEBUG=yes, which puts debugging
> information for every program (and library?) in /usr/libdata/debug/.

Back in my vendor support days, we finally convinced some labs not to
strip their binaries.  It wasn't helpful all that often, but when it was
it often saved a cycle of building a debug binary, shipping the debug
binary, getting the customer to install it, reproducing the problem, and
then starting to debug the issue in question.

Just getting hold of a core file and taking things from there was a lot
easier, and even if specific instrumentation had to be created we had a
better starting point.

I should note though we weren't trying to fit a distribution on a single
CD: we'd already gone (for dubious reasons outside my influence) to
multiple DVDs. Yeah, bloat. BIG bloat. :-(

> What if we introduced two new sets for debugging information, debug.tgz
> and xdebug.tgz (for the X11 bits), and an option to divide a release
> between the usual ISO9660 image and a second image that holds just the
> debug sets---e.g., i386cd.iso and i386debugcd.iso?

I like -- providing the documentation is nice and clear that people
only need the i386cd.iso for installation, and can grab the other
one later at need if they want.

I'm ambivalent about a DVD image: based on Linux experience (I sup with
a long spoon, it's OK :-) I'd expect more on a DVD than the install CD
contains, so if we go for a DVD image as well as the existing CD install
iso I'd like to see pkgsrc on it.  Which yes brings up the different
release schedule for pkgsrc as a complication, I know. Sorry. :-(

But I'm not wanting to turn this into a bike shed discussion, so if you
do something, do what you think best, and you have a solid +1 from me
for having debug information available that matches the release bits
however you arrange it.

(BTW, what's the state of post-mortem debugging of kernel panics these
days?  I've used a (far!) better (but proprietary :-() debugger than gdb
and have always hated trying to do anything outside user space with gdb,
but would you be including debug information for GENERIC et al?)

Giles


Home | Main Index | Thread Index | Old Index