PATCH: set_thread_buffer fixed

Gerard Patel 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 :-/

<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





More information about the wine-devel mailing list