Dave Anderson wrote: >> Item (ii) is the big deal for us. Our current virt-* tools can work >> with a wide range of kernels. >> >> What we do is to download the kernel-debuginfo packages beforehand, >> extract only the tiny amount of debug info we actually need from >> vmlinux, and build a 'kernel database'. (We're using dwarves to get >> the layout of the dozen or so structures that we care about). It >> turns out that it's quite easy to heuristically determine the version >> of a running kernel, and from that we can look up the structures in >> the kernel database at runtime. We do a similar task for a project we have for automatically setting up crash environments for a given vmcore file. >> Upshot is that we support currently ~ 350 kernels with a database >> which is a modest 1 MB in size, and probably could be made smaller >> with very little effort. >> >> The problem I haven't yet resolved with using crash is that we need a >> matching, identical vmlinux image (ie. 50-100 MB) per guest kernel >> version. In the case where we see a kernel version we've not seen >> before, we may have to download this and store it somewhere. >> >> The alternative seems to involve some really deep hacking inside gdb, >> perhaps so it can be persuaded to use only partial debug info? >> >> I don't know if you have any thoughts about (ii). Sounds like another possible use for the "debuginfo-server" idea that comes up periodically. There are a couple of things that could benefit from a centralised way of managing a collection of kernel (or other package) debug data. It needn't be anything spectacularly clever - even a few scripts that pull down debuginfo packages to an NFS exported file system and unpack them in some predictable way would be a start. Regards, Bryn. -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
