[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: implementing linux mmap2 syscall
From: Kenneth Culver <culverk () alpha ! yumyumyum ! org>
Date: 2002-04-25 2:02:12
[Download RAW message or body]
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic