Re: open stub in libc trashing word in caller's frame?
Re: open stub in libc trashing word in caller's frame?
- Subject: Re: open stub in libc trashing word in caller's frame?
- From: R.Matthew Emerson <email@hidden>
- Date: Wed, 19 Nov 2008 17:21:51 -0500
On Nov 19, 2008, at 3:23 PM, Dave Zarzycki wrote:
The callee is not setting up the stack frame correctly. mode_t is a
short, but it must be word aligned on the stack. One can observe
this fact by reviewing what GCC actually generates by this code:
[...]
But in this case, there is no mode argument for the caller to properly
align.
I'm sorry if I'm being thick, but if I call the open stub in libc with
only two arguments, e.g. like with open(path, O_RDONLY), isn't the
libc stub trashing the word where a mode argument would be if I'd
called it with 3 arguments?
So if we do something like
pushl <precious stuff>
pushl $O_RDONLY
pushl <address of path>
call _open
then, the <precious stuff> word on stack below the O_RDONLY word is
going to get its high half zeroed.
On Nov 19, 2008, at 11:25 AM, R.Matthew Emerson wrote:
I work on a Common Lisp compiler.
We have a way to call C library functions from the lisp. We
process the C headers with a custom ffigen and use the resulting
data to know the C types, number of arguments, and so forth.
When we call open(2) on 32-bit x86, though, something odd seems to
be happening.
From the libc sources (Libc-498/sys/open.c), we see
/*
* open stub: The legacy interface never automatically associated a
controlling
* tty, so we always pass O_NOCTTY.
*/
int
open(const char *path, int flags, mode_t mode)
{
return(__open_nocancel(path, flags | O_NOCTTY, mode));
}
and the code for this (on Mac OS X 10.5.5) is
0x90925a44 <open>: push ëp
0x90925a45 <open+1>: mov %esp,ëp
0x90925a47 <open+3>: mov 0xc(ëp),êx
0x90925a4a <open+6>: movzwl 0x10(ëp),íx ; [1]
0x90925a4e <open+10>: or $0x20000,êx
0x90925a53 <open+15>: mov íx,0x10(ëp) ; [2]
0x90925a56 <open+18>: mov êx,0xc(ëp)
0x90925a59 <open+21>: leave
0x90925a5a <open+22>: jmp 0x908a0e88 <open$NOCANCEL$UNIX2003>
The problem here is that if we call this with only two args, this
code will trash a word in the caller's frame (see [1] and [2]
marked above).
Like I mentioned, we see the
int open(const char *, int, ...)
prototype in fcntl.h, and don't know anything about the
__DARWIN_ALIAS_C(open) stuff, which is why we end up calling the
"legacy" interface.
Do I need some remedial i386 ABI instruction? Or is something else
wrong?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden