[Crash-utility] question about phys_base

[HATAYAMA Daisuke]

From: Wen Congyang <wency at cn.fujitsu.com>
Subject: Re: [Crash-utility] question about phys_base
Date: Wed, 29 Feb 2012 14:01:44 +0800

> At 02/29/2012 09:04 AM, HATAYAMA Daisuke Wrote:
>> From: Dave Anderson <anderson at redhat.com>
>> Subject: Re: [Crash-utility] question about phys_base
>> Date: Tue, 28 Feb 2012 09:44:09 -0500 (EST)
>> 
>>>
>>>
>>> ----- Original Message -----
>>>> At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
>>>
>>>>>>> In general, such characteristic should not be used. You should prepare
>>>>>>> a solid interface. Even if using them, it should be limited to as
>>>>>>> workaround to avoid some issue.
>>>>>>>
>>>>>>> Why not use qemu's CPU state? Include it as note information with good
>>>>>>> name, and we can use it to distinguish which. Like:
>>>>>>>
>>>>>>> $ readelf -n vmcore
>>>>>>>
>>>>>>> Notes at offset 0x000001c8 with length 0x00000838:
>>>>>>>   Owner         Data size       Description
>>>>>>>   CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>>>>>   CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>>>>>   QEMU          0x00000557      Unknown note type: (0x00000000)
>>>>>>>
>>>>>>> Or QEMUCPUState is better?
>>>>>>
>>>>>> Good idea. I will try it, and hope gdb can also work.
>>>>>>
>>>>>
>>>>> Tools basically ignore unknown notes. Looking into gdb, it appears to
>>>>> ignore unknown information.
>>>>>
>>>>> static bfd_boolean
>>>>> elfcore_grok_note (bfd *abfd, Elf_Internal_Note *note)
>>>>> {
>>>>>   const struct elf_backend_data *bed = get_elf_backend_data (abfd);
>>>>>
>>>>>   switch (note->type)
>>>>>     {
>>>>>     default:
>>>>>       return TRUE;
>>>>> <cut>
>>>>>
>>>>> You might need to add new command to output contents of new note if
>>>>> it's necessary.
>>>>
>>>> My goal is:
>>>> 1. gdb uses NT_PRSTATUS, and can work well
>>>> 2. crash uses unknown notes, and can get phys_base from it.
>>>>
>>>> Another question:
>>>>
>>>> What is QEMUCPUState? I donot find its definition?
>>>
>>> It's just the note's name character string.  Either "QEMU", "QEMUCPUState",
>>> or whatever unique character string you prefer would suffice.
>>>
>>>> What note->type shoule be for "QEMU"? If we choose an unused value, the
>>>> value may be used in the future.
>>>
>>> Why not do the same thing as the "VMCOREINFO" note, and leave it
>>> as an "illegal/unknown" type of 0::
>>>
>>>   $ cat /usr/include/elf.h
>>>   ... [ cut ] ...
>>>
>>>   /* Legal values for note segment descriptor types for core files. */
>>>
>>>   #define NT_PRSTATUS     1               /* Contains copy of prstatus struct */
>>>   #define NT_FPREGSET     2               /* Contains copy of fpregset struct */
>>>   #define NT_PRPSINFO     3               /* Contains copy of prpsinfo struct */
>>>   ...
>>>   $
>>>
>>>   $ readelf -a vmcore
>>>   ... [ cut ] ...
>>>
>>>   Notes at offset 0x00000190 with length 0x00000f1c:
>>>     Owner         Data size       Description
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     CORE          0x00000150      NT_PRSTATUS (prstatus structure)
>>>     VMCOREINFO            0x000003e4      Unknown note type: (0x00000000)
>>>   $
>>>
>> 
>> It looks OK to me for now.
>> 
>> But rigorously, it might be better to give it a name QEMU and then
>> prepare variety of information such as NT_CPUSTATE and others to be
>> needed later.
> 
> I see. I think we should decide what information should be stored in QEMUCPUState.
> The CPUState in qemu cannot be used directly, because it may be changed in the furture.
> I think all CPU register should be stored in QEMUCPUState. Do we need other information?
> 

For future incompatibility of CPUState, I think it useful to design
note information so that what kinds of values are contained there, for
example, by appending versions indicating that uniquely in the
begginning of the data.

Now the things I come up with are the CPUState only. I think it's
better for you to make the question on qemu mailing list too.

Thanks.
HATAYAMA, Daisuke