crash-utility-bounces@xxxxxxxxxx wrote on 05.05.2006 17:34:44: > > But I still think, it is best to just add an elf core command to crash and > > do the rest of user space debugging with gdb... > > I agree with Michael. But I would point out that as someone who has been > doing UNIX kernel crash dump analysis for over fifteen years I can count > the number of times I've really needed the ability to extract the user > state of processes using both hands and feet. So this is definitely > worthwhile (especially if it can be easily implemented), but is low > priority in comparison to some of the other enhancements that have been > proposed. Right! > Among the high priority needs are: > > 1) Cross architecture support. It is really painful for me to have to find > a ppc64 or s390x system with enough dasd and other resources to perform > an analysis. Given that most of tthe problems I look at do not involve > architecture specific issues it would be really useful if I could analyze > ppc64 and s390(x) dumps on a x86 or x86_64 system. Right, this is something, we from Linux for zSeries desperately need. In Böblingen we currently only use cross lcrash on an intel dump server, which can debug s390 and s390x dumps. This is an important reason, why crash currently is no option for us. > 2) Scripting support. I'd prefer to see a commonly used scripting language > such as perl or python be integrated rather than something like SIAL be > invented. There is a project named "Alicia" that is working to integrate > perl with crash. But I haven't had time to play with it so I can't say how > well it works. Right, we have kernel areas, where we are dependent on the scripting support in lcrash. One example is our s390x common IO layer, where we could have hunderds of device structures, which you can't parse by hand. Here we use lcrash sial scripts to do the analysis. But I would really vote for a C-like language. This is definitely a big advantage of sial, since you can copy kernel code and data structures 1:1 into your analysis scripts! > > 3) Making as much of the current crash initialization optional as possible > so that we have a hope of getting useful info (e.g., dmesg buffer) out of > the dump. I also agree here! Especially, if your kernel crashes at a very early time during booting or big memory areas are damaged, this feature is very important! Michael
