Alright, so I got tired of trying to figure out if glibc is doing
something wierd or wrong so I downloaded the source for it, and I'm
looking at it now... (for version 2.2.2 which is what we have on FreeBSD's
linux_base-7) and here's what I'm seeing:

pushl %ebp
        pushl %ebx
        pushl %esi
        pushl %edi

        movl OFFLO(%esp), %edx
        movl OFFHI(%esp), %ecx
        testl $0xfff, %edx
        jne L(einval)
        shrdl $12, %ecx, %edx           /* mmap2 takes the offset in
pages.  */
        shrl $12, %ecx
        jne L(einval)
        movl %edx, %ebp

So above I'm seeing the offset arg get into register %ebp, which is what
we expect...

        movl ADDR(%esp), %ebx
        movl LEN(%esp), %ecx
        movl PROT(%esp), %edx
        movl FLAGS(%esp), %esi
        movl FD(%esp), %edi

Then I'm seeing all the other args getting put into the registers they
belong in... (which matches up with our linux_prepsyscall() function)

        movl $SYS_ify(mmap2), %eax      /* System call number in %eax.  */

        /* Do the system call trap.  */
L(do_syscall):
        int $0x80

Now I'm seeing the int 0x80 trap....

        /* Restore registers.  */
        popl %edi
        popl %esi
        popl %ebx
        popl %ebp


So, as far as I can tell, this version of glibc is doing the Right Thing,
and the ebp register is getting messed up somewhere along the line in
either the assembly code that handles the 0x80 trap in FreeBSD, or in
syscall2 (I think it's probably the asm that handles the 0x80 trap)...

Can anyone confirm this?

Ken


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to