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
