From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18652 invoked by alias); 18 Dec 2007 08:39:49 -0000 Received: (qmail 18643 invoked by uid 22791); 18 Dec 2007 08:39:48 -0000 X-Spam-Check-By: sourceware.org Received: from caffeine.csclub.uwaterloo.ca (HELO caffeine.csclub.uwaterloo.ca) (129.97.134.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 08:39:44 +0000 Received: from caffeine.csclub.uwaterloo.ca (localhost [127.0.0.1]) by caffeine.csclub.uwaterloo.ca (Postfix) with ESMTP id 8AF7573C6F for ; Tue, 18 Dec 2007 03:39:42 -0500 (EST) Received: by caffeine.csclub.uwaterloo.ca (Postfix, from userid 20006) id 78BA073CC4; Tue, 18 Dec 2007 03:39:42 -0500 (EST) To: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack Message-Id: <20071218083942.78BA073CC4@caffeine.csclub.uwaterloo.ca> Date: Tue, 18 Dec 2007 11:55:00 -0000 From: rridge@csclub.uwaterloo.ca (Ross Ridge) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00516.txt.bz2 Ross Ridge writes: > This section doesn't make sense to me. The force_align_arg_pointer > attribute and -mstackrealign assume that the ABI is being > followed, while the -fpreferred-stack-boundary option effectively "H.J. Lu" writes > According to Apple engineer who implemented the -mstackrealign, > on MacOS/ia32, psABI is 16byte, but -mstackrealign will assume > 4byte, which is STACK_BOUNDARY. Ok. The importanting thing is that for backwards compatibility it needs to continue to assume 4-byte alignment on entry and align the stack to a 16-byte alignment on x86 targets, so that makes more sense. >> changes the ABI. According your defintions, I would think >> that INCOMING should be ABI_STACK_BOUNDARY in the first case, >> and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second. > > That isn't true since some .o files may not be compiled with > -fpreferred-stack-boundary or with a different value of > -fpreferred-stack-boundary. Like with any ABI changing flag, that's not supported: ... Further, every function must be generated such that it keeps the stack aligned. Thus calling a function compiled with a higher preferred stack boundary from a function compiled with a lower preferred stack boundary will most likely misalign the stack. The -fpreferrred-stack-boundary flag currently generates code that assumes the stack aligned to the preferred alignment on function entry. If you assume a worse incoming alignment you'll be aligning the stack unnecessarily and generating code that this flag doesn't require. > On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may > want to use 8 byte for PREFERRED_STACK_BOUNDARY. Ok, if people are using this flag to change the alignment to something smaller than used by the standard ABI, then INCOMING should be MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY). Ross Ridge