Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: open stub in libc trashing word in caller's frame?


On Nov 19, 2008, at 5:10 PM, R. Matthew Emerson wrote:


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. 

R.Matthew Emerson,

Good call. Please file a bug.

davez



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   %ebp
0x90925a45 <open+1>:	mov    %esp,%ebp
0x90925a47 <open+3>:	mov    0xc(%ebp),%eax
0x90925a4a <open+6>:	movzwl 0x10(%ebp),%edx     ; [1]
0x90925a4e <open+10>:	or     $0x20000,%eax
0x90925a53 <open+15>:	mov    %edx,0x10(%ebp)     ; [2]
0x90925a56 <open+18>:	mov    %eax,0xc(%ebp)
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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >open stub in libc trashing word in caller's frame? (From: R.Matthew Emerson <email@hidden>)
 >Re: open stub in libc trashing word in caller's frame? (From: Dave Zarzycki <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.