[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Time to deprecate crash dump support in stats tools (or KVM-grovelers in general)?
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.
Main Index |
Thread Index |