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! Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux