From mboxrd@z Thu Jan 1 00:00:00 1970 From: PUCCETTI Armand Subject: x86_64 platform : addresses type Date: Tue, 04 Jul 2006 12:27:19 +0200 Message-ID: <44AA4287.9090307@cea.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1039695648==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1039695648== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Several addresses are actually on 32 bits, such as in

typedef struct {
   u32 flags;
   u32 mem_lower;
   u32 mem_upper;
   u32 boot_device;
   u32 cmdline;
   u32 mods_count;
   u32 mods_addr;
   union {
       aout_symbol_table_t aout_sym;
       elf_section_header_table_t elf_sec;
   } u;
   u32 mmap_length;
   u32 mmap_addr;
} multiboot_info_t

However, on x86_64 using gcc, addresses as well as unsigned long are 64 bits long.

It seems that luckily mmap_addr is below 2*32-1, making the u32 type acceptable
so far (for instance in function __start_xen, where the memory map is turned into
another structure) but what would it cost to change it into u64 ?
After all, the multiboot specification (page 18) has 'unsigned long' instead of u32 here.

--===============1039695648== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1039695648==--