PATCH: set_thread_buffer fixed

[Gerard Patel]

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