[Crash-utility] Re: crash enhancements proposal

[Maneesh Soni]

On Fri, May 05, 2006 at 08:34:44AM -0700, Kurtis D. Rader wrote:
> On Fri, 2006-05-05 16:20:27, Michael Holzheu wrote:
> > I also always thought that it is not necessary to debug userspace stuff in
> > crash dumps. Some weeks ago, ...
> > 
> > There they used the lcrash core command to extract the elf cores for all
> > the userspace programs. At least it was possible to get the userspace
> > stackbacktraces ...
> > 
> > So I think for very complex installations, there are cases, where it makes
> > sense to just snapshot the whole system with a crash dump.
> > 
> > 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.
> 
> 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.

Agreed, this is also necessary as an added advantage for the service people. 

> 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.
> 
gdb itself have some scripting support probably not as advanced as perl or
python. Though I have never tried invoking gdb scripts via crash but I think
it should be possible. I have anyway included this also in the new list.

> 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.
> 
> All of the other proposals have merit but are nowhere near as important
> as the above. Also, in some cases it isn't going to be possible to fully
> implement the proposed functionality. For example, you can't always display
> the arguments to a function thanks to the new "fastcall" attribute which
> causes arguments to be passed via registers. So tasks like stack analysis
> are always going to require human intelligence.

Agreed. But I think some platforms like ppc64 might behave better which
always use registers for passing parameters.

Thanks
maneesh