PATCH: set_thread_buffer fixed

Marcus Meissner Marcus.Meissner at caldera.de
Tue Jun 5 03:43:59 CDT 2001


On Tue, Jun 05, 2001 at 10:08:48AM -0400, Gerard Patel wrote:
> At 07:20 AM 05/06/2001 +0200, you wrote:
> 
> >Not really, as Alexandre said.
> >
> >Could you please test the attached small test program?
> 
> It fails (of course).
> 
> Here is the call with my working computer (glibc2.2, linux 2.4)
> 
> 0x8048668 <main+72>:    call   0x8048464 <write>
> 0x804866d <main+77>:    add    $0xc,%esp
> 0x8048670 <main+80>:    push   $0x0		\ off64_t
> 0x8048672 <main+82>:    push   $0x0		/ 
> 0x8048674 <main+84>:    push   %ebx		- fd
> 0x8048675 <main+85>:    push   $0x1		- MAP_*
> 0x8048677 <main+87>:    push   $0x3		- PROT_*
> 0x8048679 <main+89>:    push   $0x4		- size_t
> 0x804867b <main+91>:    push   $0x0		- ptr_t
> 0x804867d <main+93>:    call   0x80484a4 <mmap64>p
> 
> For the failing one :
> 
> 0x80486c8 <main+72>:    call   0x80484dc <write>
> 0x80486cd <main+77>:    addl   $0x20,%esp
> 0x80486d0 <main+80>:    addl   $0xfffffff8,%esp
> 0x80486d3 <main+83>:    pushl  $0x0		_ off_t, 32bit !(esp+24)
> 0x80486d5 <main+85>:    pushl  %ebx		- fd		(esp+20
> 0x80486d6 <main+86>:    pushl  $0x1		- MAP_*		(esp+16)
> 0x80486d8 <main+88>:    pushl  $0x3		- PROT_*	(esp+12)
> 0x80486da <main+90>:    pushl  $0x4		- size_t	(esp+8)
> 0x80486dc <main+92>:    pushl  $0x0		- ptr_t		(esp+4)
> 0x80486de <main+94>:    call   0x804851c <mmap64> 
> 
> 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!

> In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source,
> there is a comment saying that the offset is 'too large'. I understand
> that the app is calling mmap64 on an operating system that is not
> supporting it (it's perfectly correct in this case, the failing box having
> 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap.

I think SYS(old_mmap) does not support it. Only SYS(mmap2), which takes
offset in blocks...

> I think that the problem is in the compilation; pushing only 6 dwords
> on the stack to call mmap64 is wrong.

> I have not yet figured out why, though (I have never been any good with
> C header problems)

Yes, check the sys/mman.h header, it should have __off64_t as argument
to the mmap ... asm("mmap64") not __off_t.

So I think I can use this test program as check for mmap64 brokeness...

Ciao, Marcus




More information about the wine-devel mailing list