Re: [Crash-utility] question about phys_base

From: Wen Congyang <wency(a)cn.fujitsu.com&gt; 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(a)cn.fujitsu.com&gt; >> 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.

Thanks. HATAYAMA, Daisuke