Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest

[Jan Kiszka]

On 2011-10-18 10:34, Richard W.M. Jones wrote:
> On Tue, Oct 18, 2011 at 10:31:10AM +0200, Jan Kiszka 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?
> 
> Crash can decode kernel structures, providing for example process
> listings and debugging into userspace processes.  Crash actually
> reuses gdb's code too, so it's kind of a superset.

Yeah, I see. Could also be solved via gdb scripts, but crash is already
there.

But let's see if the formats actually differ. In the end, crash is just
parsing the same information that also gdb sees.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux