PATCH: set_thread_buffer fixed
gerard.patel at nerim.net
Tue Jun 5 11:14:52 CDT 2001
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, 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,
is nothing like it in the glibc source that I used to compile. The mman.h in
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
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.
More information about the wine-devel