On 2011-10-20 03:22, Wen Congyang wrote: >>> I didn't read full story but 'crash' is used for investigating kernel core >>> generated >>> by kdump for several years. Considering support service guys, virsh dump >>> should support >>> a format for crash because they can't work well at investigating vmcore by >>> gdb. >>> >>> crash has several functionality useful for them as 'show kerne log', 'focus >>> on a cpu' >>> 'for-each-task', 'for-each-vma', 'extract ftrace log' etc. >>> >>> Anyway, if a man, who is not developper of qemu/kvm, should learn 2 tools >>> for >>> investigating kernel dump, it sounds harmful. >> >> Right, that's why everything (live debugging & crash analysis) should be >> consolidated on the long run over gdb. crash is architecturally obsolete >> today - not saying it is useless! > > I do not know why crash is obsoleted today. Is there a new better tool to > instead > crash?
I'm not aware of equally powerful (python) scripts for gdb as replacement, but I think it's worth starting a porting effort at some point. > > At least, I always use crash to live debugging & crash analysis. Then you may answer some questions to me: - Can you attach to a remote target (kgdb, qemu, etc.) and how? - Can you use it with latest gdb versions or is the gdb functionality hard-wired due to an embedded gdb core in crash (that's how I understood Christoph's reply to this topic) Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
