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 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 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 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 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.
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 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)
Gerard
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