site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Sorry for the delay... I found your problem, and it's an interesting one. vm_size_t mac_pagesize; [ ... ] host_page_size(host_port, &mac_pagesize); ... host_page_size(host_port, &mac_pagesize); the Darwin kernel does this: kern_return_t host_page_size( host_t host, vm_size_t *out_page_size) { if (host == HOST_NULL) return(KERN_INVALID_ARGUMENT); *out_page_size = PAGE_SIZE; return(KERN_SUCCESS); } --Jim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Jun 4, 2005, at 11:27 AM, Tony Scaminaci wrote: On Jun 2, 2005, at 1:43 AM, William Kucharski wrote: The problem lies here in your code and the fact that you have your project set to be compiled in 64-bit mode for G5s: What this means is if __ppc__ is defined, vm_size_t will be an unsigned int (size 4 bytes); if __ppc64__ is defined, vm_size_t will be a unintptr_t (size 4 bytes on PPC32, 8 bytes on PPC64.) The problem is that the kernel is NOT a 64-bit executable, and as such is not compiled with __ppc64__ set, so when you make this call from a 64-bit executable: I think you probably see the issue here; Yep, this is a bug with host_page_size(). Since it is a message to the Mach kernel, it doesn't have the information about what kind of address space the caller has, and therefore can only fill in the legacy size. The usual approach we took in these situations was to add a second RPC for 64-bit clients (and then aliased the name in the build of the 64-bit Libc). But this one slipped through the cracks. Why wouldn't it fill in the lower four bytes instead? I ask this because when I print out mac_pagesize, I do get 4096 as expected so the lower bytes must have the correct value. As someone else explained, the printf directive you used triggers the same "looking at the wrong bytes" issue as the host_page_size results output did. If you look in the debugger (on big-endian PowerPC), you'll see the big number. The question is, what SHOULD happen in this case, and should there be an ADC tech note warning of this issue? According to the Darwin 64-bit conversion guide (<http:// developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/ index.html>), "Only libSystem and the Accelerate framework are available to 64-bit developers. Higher level frameworks are 32-bit only." But is a call to host_page_size() really considered a "higher level framework?" I'd consider host_page_size() to be part of libSystem if anything. If we can't address more than 4 GB of memory, what's the point of having a 64-bit OS and a PPC G5? At the very least, Tiger should be able to get at all of the user's installed memory assuming the user runs a 64-bit app. How can the kernel handle more than 4 GB of address space if it's not 64-bit? The host_page_size() returning the wrong thing in 64-bit land doesn't make it so you "can't address more than 4GB of memory." Yep, it's a bug. How could this slip through? Because Libc, through mach_init (), provides a global "vm_page_size" for this value. It is initialized differently for 64-bit processes (as you guessed it - hard coded for now). The intent was to move to use of a value in the commpage (memory shared between the kernel and user-space containing such configuration values). That value would be used to initialize both the global and the return value for host_page_size(). We didn't quite get there - and you see the results. There's got to be a simple workaround to this problem. I can't be the only person trying to use more than 4GB of memory at one time. Any application that bills itself as 64-bit has to address these issues. So, my suggestion is to use the Libc-provided vm_page_size global instead of calling host_page_size() yourself. Heck it's even more efficient. And you don't have to worry about releasing the host port reference returned from mach_host_self() (which hardly anyone does correctly). This email sent to site_archiver@lists.apple.com