qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 09/14 v7] introduce a new monitor command '


From: Wen Congyang
Subject: Re: [Qemu-devel] [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump guest's memory
Date: Thu, 01 Mar 2012 15:21:46 +0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100413 Fedora/3.0.4-2.fc13 Thunderbird/3.0.4

At 03/01/2012 03:04 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang <address@hidden>
> Subject: [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump 
> guest's memory
> Date: Thu, 01 Mar 2012 10:51:42 +0800
> 
>> +    /*
>> +     * calculate phdr_num
>> +     *
>> +     * the type of phdr->num is uint16_t, so we should avoid overflow
>> +     */
>> +    s->phdr_num = 1; /* PT_NOTE */
>> +    if (s->list.num > (1 << 16) - 2) {
>> +        s->phdr_num = (1 << 16) - 1;
>> +    } else {
>> +        s->phdr_num += s->list.num;
>> +    }
>> +
>> +    return s;
>> +}
> 
> Though e_phnum is uint16_t at default, there's extension up to
> uint32_t. Look at relatively new manual page. This is from FC14's.
> 
>      e_phnum     This member  holds the number of  entries in the
>                  program  header  table.   Thus  the  product  of
>                  e_phentsize and  e_phnum gives the  table's size
>                  in  bytes.  If  a  file has  no program  header,
>                  e_phnum holds the value zero.
> 
>                  If the  number of entries in  the program header
>                  table  is  larger   than  or  equal  to  PN_XNUM
>                  (0xffff), this member holds PN_XNUM (0xffff) and
>                  the real number of entries in the program header
>                  table  is  held in  the  sh_info  member of  the
>                  initial   entry   in   section   header   table.
>                  Otherwise,  the sh_info  member  of the  initial
>                  entry contains the value zero.
> 
>                  PN_XNUM  This is defined  as 0xffff, the largest
>                           number  e_phnum  can  have,  specifying
>                           where  the  actual  number  of  program
>                           headers is assigned.

Good news.

> 
> Recent kernel, gdb and tools in binutils supports this. But crash
> doesn't, so you need to fix this.

I think it can be easily fixed.

> 
> I'm interested in the number of program headers at worst
> case. According to Intel Programming Guide 3A, Table 4-1. shows
> physical-address width on IA-32e is up to 52 and linear-address width
> is 48. Can the number exceed this limit in theory? Also how many
> program headers are created typically?

In my test, the guest has 512M memory, and it contains about 1000~2000 program
headers.

In theory, if the guest has 2^52 memory, the number can still exceed this limit.
Tha maxnium number is 2^52/2^12

Thanks
Wen Congyang

> 
> Thanks.
> HATAYAMA, Daisuke
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]