At 10/19/2011 07:40 PM, Jan Kiszka Write: > On 2011-10-19 04:04, KAMEZAWA Hiroyuki wrote: >> On Tue, 18 Oct 2011 10:31:10 +0200 >> Jan Kiszka <jan.kis...@siemens.com> wrote: >> >>> On 2011-10-18 10:31, Wen Congyang wrote: >>>> At 10/18/2011 04:26 PM, Jan Kiszka Write: >>>>> On 2011-10-18 10:25, Wen Congyang wrote: >>>>>> At 10/18/2011 04:19 PM, Jan Kiszka Write: >>>>>>> On 2011-10-18 09:58, Wen Congyang wrote: >>>>>>>> At 10/18/2011 03:52 PM, Jan Kiszka Write: >>>>>>>>> On 2011-10-18 09:15, Wen Congyang wrote: >>>>>>>>>> Hi, Jan Kiszka >>>>>>>>>> >>>>>>>>>> At 10/10/2011 05:34 PM, Jan Kiszka Write: >>>>>>>>>>> On 2011-10-10 11:02, Daniel P. Berrange wrote: >>>>>>>>>>>> On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Run gdb with "set debug remote 1" and watch the communication, it >>>>>>>>>>> is not >>>>>>>>>>> that complex. But a dump command is probably simpler for those >>>>>>>>>>> scenarios, I agree. >>>>>>>>>> >>>>>>>>>> I have implemented the command dump and reuse migration's code. But >>>>>>>>>> I meet a problem >>>>>>>>>> when I test it. >>>>>>>>> >>>>>>>>> Using migration code for dump is most probably the wrong approach as >>>>>>>>> you >>>>>>>>> saw through that conflict. All you need are the register states and >>>>>>>>> the >>>>>>>>> RAM. Reuse gdbstub services for this. >>>>>>>> >>>>>>>> Hmm, if the migration code can not be reused, I think we should define >>>>>>>> a new >>>>>>>> qemu's vmcore format, and add some codes into crash to support such >>>>>>>> format. >>>>>>> >>>>>>> Please try to avoid defining something new. Unless there is a striking >>>>>>> reason, standard gdb core files should be generated so that you can load >>>>>>> the dump directly into gdb for analysis. >>>>>> >>>>>> I am not sure whehter the standard gdb core files can not be analyzed by >>>>>> crash. >>>>>> If not, I think we should define something new because it's easier to use >>>>>> crash than gdb to analyze the core files. >>>>> >>>>> gdb allows you to walk up the frame and print variables (globals & >>>>> local) etc. >>>> >>>> Crash uses gdb to provide common function, and you can also use all the >>>> gdb commands >>>> in crash. >>> >>> That what's the added value here when I can use gdb directly? >>> >> >> 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? At least, I always use crash to live debugging & crash analysis. Thanks Wen Congyang > > Jan >
