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