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. Thanks Wen Congyang > > Jan >
