FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 02-28-2012, 07:36 AM
Wen Congyang
 
Default question about phys_base

At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [Crash-utility] question about phys_base
> Date: Tue, 28 Feb 2012 13:10:38 +0800
>
>> At 02/27/2012 10:10 PM, Dave Anderson Wrote:
>
>>>> The guest is in the second kernel(vcpu > 1)
>>>> ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>> LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000
>>>
>>> Again, it's not clear why there are multiple segments with the same
>>> same virtual address, but I'm guessing that the one segment that starts
>>> at 0x0000000004000000 is associated with the second kernel, and the other
>>> ones are for vcpus that ran in the first kernel?
>>>
>>>> The guest is in the second kernel(vcpu = 1)
>>>> [root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
>>>> LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000
>>>>
>>>> I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
>>>> headers.
>>>
>>> Kdump-generated vmcores cannot have multiple START_KERNEL_map segments.
>>> But with dumps where (vpcu = 1), there could be confusion since it's not obvious
>>> if START_KERNEL_map region belongs to the first or second kernel.
>>>
>>> That being the case, I don't see how this can be supported cleanly by the crash'
>>> utility unless there is a NOTE, or some other obvious identifier, that absolutely
>>> confirms that the dumpfile was qemu-generated.
>>
>> The note information stored in qemu-generated core:
>> Program Headers:
>> Type Offset VirtAddr PhysAddr
>> FileSiz MemSiz Flags Align
>> NOTE 0x000000000000edd0 0x0000000000000000 0x0000000000000000
>> 0x0000000000000590 0x0000000000000590 0
>>
>> I think its format is the same as kdump's vmcore. Does kdump-generated core's
>> virtaddr is always 0? If so, What about to set virt_addr to -1 in qemu-generated
>> core?
>>
>
> 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.

Thanks
Wen Congyang


>
> Thanks.
> HATAYAMA, Daisuke
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-28-2012, 08:04 AM
Wen Congyang
 
Default question about phys_base

At 02/28/2012 04:52 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
> Subject: Re: [Crash-utility] question about phys_base
> Date: Tue, 28 Feb 2012 16:36:59 +0800
>
>> At 02/28/2012 02:30 PM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang <wency@cn.fujitsu.com>
>>> Subject: Re: [Crash-utility] question about phys_base
>>> Date: Tue, 28 Feb 2012 13:10:38 +0800
>>>
>>>> At 02/27/2012 10:10 PM, Dave Anderson Wrote:
>>>
>>>>>> The guest is in the second kernel(vcpu > 1)
>>>>>> ]# readelf /tmp/vm2.save2 -l| grep 0xffffffff8
>>>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>>>> LOAD 0x0000000001017be0 0xffffffff81000000 0x0000000001000000
>>>>>> LOAD 0x0000000004017be0 0xffffffff81000000 0x0000000004000000
>>>>>
>>>>> Again, it's not clear why there are multiple segments with the same
>>>>> same virtual address, but I'm guessing that the one segment that starts
>>>>> at 0x0000000004000000 is associated with the second kernel, and the other
>>>>> ones are for vcpus that ran in the first kernel?
>>>>>
>>>>>> The guest is in the second kernel(vcpu = 1)
>>>>>> [root@ghost ~]# readelf /tmp/vm2.save3 -l| grep 0xffffffff8
>>>>>> LOAD 0x0000000004001e4c 0xffffffff81000000 0x0000000004000000
>>>>>>
>>>>>> I donot find differentiate qemu-genetated ELF headers from dump-generated ELF
>>>>>> headers.
>>>>>
>>>>> Kdump-generated vmcores cannot have multiple START_KERNEL_map segments.
>>>>> But with dumps where (vpcu = 1), there could be confusion since it's not obvious
>>>>> if START_KERNEL_map region belongs to the first or second kernel.
>>>>>
>>>>> That being the case, I don't see how this can be supported cleanly by the crash'
>>>>> utility unless there is a NOTE, or some other obvious identifier, that absolutely
>>>>> confirms that the dumpfile was qemu-generated.
>>>>
>>>> The note information stored in qemu-generated core:
>>>> Program Headers:
>>>> Type Offset VirtAddr PhysAddr
>>>> FileSiz MemSiz Flags Align
>>>> NOTE 0x000000000000edd0 0x0000000000000000 0x0000000000000000
>>>> 0x0000000000000590 0x0000000000000590 0
>>>>
>>>> I think its format is the same as kdump's vmcore. Does kdump-generated core's
>>>> virtaddr is always 0? If so, What about to set virt_addr to -1 in qemu-generated
>>>> core?
>>>>
>>>
>>> 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?
What note->type shoule be for "QEMU"? If we choose an unused value, the
value may be used in the future.

Thanks
Wen Congyang

>
> Thanks.
> HATAYAMA, Daisuke
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-28-2012, 01:44 PM
Dave Anderson
 
Default question about phys_base

----- 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)
$

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 02-29-2012, 05:01 AM
Wen Congyang
 
Default question about phys_base

At 02/29/2012 09:04 AM, HATAYAMA Daisuke Wrote:
> From: Dave Anderson <anderson@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?

Thanks
Wen Congyang

>
> Thanks.
> HATAYAMA, Daisuke
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 04:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org