At 10:43 AM 05/06/2001 +0200, you wrote:
This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine.
Well, note that the second version is only pushing a 32bit offset, so mmap64 accesses random stack space!
Yes :-/
<snip>
Yes, check the sys/mman.h header, it should have __off64_t as argument to the mmap ... asm("mmap64") not __off_t.
Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/
So I think I can use this test program as check for mmap64 brokeness...
Btw, the reference on large files
http://www.suse.de/~aj/linux_lfs.html
says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case.
Gerard
-
Gerard Patel