From owner-freebsd-amd64@FreeBSD.ORG  Mon Dec  1 21:57:42 2003
Return-Path: <owner-freebsd-amd64@FreeBSD.ORG>
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 1839016A4D2
	for <freebsd-amd64@freebsd.org>; Mon,  1 Dec 2003 21:57:42 -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 0856443F75
	for <freebsd-amd64@freebsd.org>;
	Mon,  1 Dec 2003 21:57:41 -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 hB25vdo8079990
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 1 Dec 2003 23:57:39 -0600 (CST)
Received: (from james@localhost)
	by bigtex.jrv.org (8.12.1/8.12.1/Submit) id hB25vdZF079987;
	Mon, 1 Dec 2003 23:57:39 -0600 (CST)
Date: Mon, 1 Dec 2003 23:57:39 -0600 (CST)
Message-Id: <200312020557.hB25vdZF079987@bigtex.jrv.org>
From: James Van Artsdalen <james-freebsd-amd64@jrv.org>
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 <freebsd-amd64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-amd64>,
	<mailto:freebsd-amd64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-amd64>
List-Post: <mailto:freebsd-amd64@freebsd.org>
List-Help: <mailto:freebsd-amd64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-amd64>,
	<mailto:freebsd-amd64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2003 05:57:42 -0000

gcc will never generate code referencing memory at addresses less than
the current value of SP.  Is there much userland code that does this?
I'd almost rather let the signal handler trash these areas so such code
can be found and fixed.

I hope to get a Tyan K8W this week and to have it sufficiently
burned-in to boot amd64 next week.

> Plus there is another hairball to deal with.. the red zone..  The
> 128 bytes below the stack pointer are reserved for private use of
> leaf functions or scratch area.  This means that the signal handlers
> need to skip over it, and anything that copies the stack has to
> include the extra 128 bytes.