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. Thanks, -Kame
