From: Wen Congyang <wency@xxxxxxxxxxxxxx>
Subject: Re: 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@xxxxxxxxxxxxxx>
>> Subject: Re: 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.
Thanks.
HATAYAMA, Daisuke
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
