From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S30Ji-0005wV-4w for qemu-devel@nongnu.org; Thu, 01 Mar 2012 02:20:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S30Jb-00082c-8P for qemu-devel@nongnu.org; Thu, 01 Mar 2012 02:20:45 -0500 Received: from [222.73.24.84] (port=49344 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S30Ja-00080q-LC for qemu-devel@nongnu.org; Thu, 01 Mar 2012 02:20:39 -0500 Message-ID: <4F4F238A.10905@cn.fujitsu.com> Date: Thu, 01 Mar 2012 15:21:46 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4F4EE080.9060307@cn.fujitsu.com> <4F4EE43E.3020309@cn.fujitsu.com> <20120301.160443.229728320.d.hatayama@jp.fujitsu.com> In-Reply-To: <20120301.160443.229728320.d.hatayama@jp.fujitsu.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC][PATCH 09/14 v7] introduce a new monitor command 'dump' to dump guest's memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HATAYAMA Daisuke Cc: jan.kiszka@siemens.com, anderson@redhat.com, qemu-devel@nongnu.org, eblake@redhat.com, lcapitulino@redhat.com At 03/01/2012 03:04 PM, HATAYAMA Daisuke Wrote: > From: Wen Congyang > 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 > >