At 02/15/2012 05:17 PM, Jan Kiszka Wrote:
> On 2012-02-15 05:07, Wen Congyang wrote:
>> At 02/15/2012 01:21 AM, Jan Kiszka Wrote:
>>> On 2012-02-09 04:22, Wen Congyang wrote:
>>>> Add API to get all virtual address and physical address mapping.
>>>> If there is no virtual address for some physical address, the virtual
>>>> address is 0.
>>>>
>>>> Signed-off-by: Wen Congyang <we...@cn.fujitsu.com>
>>>> ---
>>>> memory_mapping.c | 65
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> memory_mapping.h | 1 +
>>>> 2 files changed, 66 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/memory_mapping.c b/memory_mapping.c
>>>> index d83b7d7..fc0ddee 100644
>>>> --- a/memory_mapping.c
>>>> +++ b/memory_mapping.c
>>>> @@ -128,3 +128,68 @@ void free_memory_mapping_list(MemoryMappingList *list)
>>>>
>>>> list->num = 0;
>>>> }
>>>> +
>>>> +void get_memory_mapping(MemoryMappingList *list)
>>>> +{
>>>> + CPUState *env;
>>>> + MemoryMapping *memory_mapping;
>>>> + RAMBlock *block;
>>>> + ram_addr_t offset, length;
>>>> +
>>>> + last_mapping = NULL;
>>>> +
>>>> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>> + cpu_get_memory_mapping(list, env);
>>>
>>> Hmm, is the CPU number recorded along with the mappings? I mean, how
>>> could crash tell them apart afterward if they are contradictory? This
>>> way, they are just thrown in the same bucket, correct?
>>>
>>> Even if crash or gdb aren't prepared for cpu/thread-specific mappings,
>>> could we already record that information for later use? Or would it
>>> break compatibility with current versions?
>>
>> crash does not need this information. It only needs the physical address
>> stored in PT_LOAD.
>
> So crash does not support viewing memory through the eyes of different
> CPUs? OK.
>
>>
>> gdb needs the virtual address and physical address stored in PT_LOAD.
>>
>> If the address is in the kernel space, the virtual address and physical
>> address mapping should be the same. I collect the mapping information
>> from all vcpus, because the OS may enter the second kernel. In this case,
>> IIRC(according to my test result, but I don't remeber clearly), gdb's bt
>> can output the backtrace in the first kernel if the OS does not use the
>> first vcpu to do kdump. otherwise gdb's bt can output the backtrace in
>> the second kernel.
>
> gdb could only make proper use of the additional mappings if they are
> not contradictory (which can easily happen with user space processes) or
> the cpu context is additionally provided so that views can be switched
> via the "thread N" command. So far, QEMU's gdbstub does this for gdb
> when it requests some memory over the remote connection. I bet gdb
> requires some extension to exploit such information offline from a core
> file, but I'm also sure that this will come as the importance of gdb for
> system level debugging will rise.
>
> Therefore my question: is there room to encode the mapping relation to a
> CPU/thread context?
I donot know. But I think the answer is no, because there is no filed
in the struct Elf32_Phdr/Elf64_Phdr to store the CPU/thread id.
Thanks
Wen Congyang
>
> Jan
>
