PATCH: set_thread_buffer fixed
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...
More information about the wine-devel