Re: Time to deprecate crash dump support in stats tools (or KVM-grovelers in general)?

[nathanw%MIT.EDU@localhost (Nathan J. Williams)]

Brian Ginsbach <ginsbach%NetBSD.org@localhost> writes:

Without weighing in on the general issue, a few points related to
crash dumps and GDB:

> Why tie analysis to GDB?  What happens when we want to go to
> abbreviated/sparse dumps because it is no longer practical to dump
> multi-gigabyte kernel core images?

This particular bit isn't a concern; the relevant uses of GDB are
using libkvm as a back-end for looking at memory anyway, so what
happens when we go to abbreviated/sparse dumps is that we teach libkvm to
read them and GDB suddenly gains that ability as well.

> Maybe we just won't worry about
> supporting that many CPUs. Using GDB also assumes that you only
> want to analyze non-stripped kernels, right?

This depends on how much you want to use the type system in
GDB. Should the script refer to "structure->member->member", then yes,
this will only work on kernels that haven't had debug/type information
stripped out of them. This is slightly annoying but doesn't strike me
as terrible; the alternative is keeping kvm-grovellers in sync with
the kernel you're running, which has its own set of problems.

It's worth noting here that the GDB script language is a pretty weak
language, and is expected to be overhauled (probably by being replaced
with some embedded Python engine) Real Soon Now.

        - Nathan