From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 16:11:08 2003 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77B7616A4CE for ; Mon, 1 Dec 2003 16:11:08 -0800 (PST) Received: from bigtex.jrv.org (rrcs-sw-24-73-246-106.biz.rr.com [24.73.246.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F8A143FB1 for ; Mon, 1 Dec 2003 16:11:06 -0800 (PST) (envelope-from james@bigtex.jrv.org) Received: from bigtex.jrv.org (localhost [127.0.0.1]) by bigtex.jrv.org (8.12.1/8.12.1) with ESMTP id hB20B5o8068507 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Dec 2003 18:11:05 -0600 (CST) Received: (from james@localhost) by bigtex.jrv.org (8.12.1/8.12.1/Submit) id hB20B4A4068504; Mon, 1 Dec 2003 18:11:04 -0600 (CST) Date: Mon, 1 Dec 2003 18:11:04 -0600 (CST) Message-Id: <200312020011.hB20B4A4068504@bigtex.jrv.org> From: James Van Artsdalen To: freebsd-amd64@freebsd.org Subject: Re: Varargs issues X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2003 00:11:08 -0000 I looked at the example I was suspicious of and realized that I had overlooked that the caller implicitly allocates 8 bytes in the stack due to the CALL opcode. It's perfectly reasonable for a function to start with something like: doo: push (64 bit) val call z since the return address + the push makes an even 16 bytes. There are two different pthread_create () functions. The one in /usr/src/lib/libc_r/uthread/uthread_create.c does this to ensure that the stack starts off right: SET_STACK_JB(new_thread->ctx.jb, (long)new_thread->stack + pattr->stacksize_attr - sizeof(double)); sizeof (double) isn't really portable - sizeof (&_pthread_create) would be better - but it clearly leaves the stack with a value that gcc expects, i.e., an "odd" value in 8-byte units (0xfff8 instead of 0xfff0). But, in /usr/src/lib/libthr/thread/thr_create.c I see this: new_thread->ctx.uc_stack.ss_sp = new_thread->stack; and no evidence anywhere that the return address gcc expects to already be pushed on the stack is accounted for. Perhaps this should be something like: new_thread->ctx.uc_stack.ss_sp = new_thread->stack; #if !defined(__ia64__) new_thread->ctx.uc_stack.ss_sp -= sizeof (&_pthread_create); #endif (I'm carrying over the assumption that stacks grow towards lower addresses) > James Van Artsdalen wrote: > > The trick is that gcc 3.3 doesn't seem to try to keep the stack > > aligned to 16-bytes, [...] > > gcc depends on the stack being correctly aligned at program entry and makes > sure it is aligned before making other function calls. You'll see this in > subtle ways, eg: it'll reserve 32 bytes of stack space instead of the 24 that > it might actually use, etc.