Re: [Crash-utility] Re: crash enhancements proposal
crash-utility-bounces(a)redhat.com 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