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