From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30602 invoked by alias); 18 Dec 2007 04:25:53 -0000 Received: (qmail 30593 invoked by uid 22791); 18 Dec 2007 04:25:52 -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 04:25:37 +0000 Received: from caffeine.csclub.uwaterloo.ca (localhost [127.0.0.1]) by caffeine.csclub.uwaterloo.ca (Postfix) with ESMTP id 4BE3D73C6F for ; Mon, 17 Dec 2007 23:25:35 -0500 (EST) Received: by caffeine.csclub.uwaterloo.ca (Postfix, from userid 20006) id 3FB1F73CC4; Mon, 17 Dec 2007 23:25:35 -0500 (EST) To: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack Message-Id: <20071218042535.3FB1F73CC4@caffeine.csclub.uwaterloo.ca> Date: Tue, 18 Dec 2007 04:29: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/msg00505.txt.bz2 Ye, Joey writes: >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386 >and 64 for x86_64. It is the minimum stack boundary. It is fixed. Strictly speaking by the above definition it would be 8 for i386. The hardware doesn't force the stack to be 32-bit aligned, it just performs poorly if it isn't. >v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary >at function entry. If a function is marked with __attribute__ >((force_align_arg_pointer)) or -mstackrealign option is provided, >INCOMING = STACK_BOUNDARY. Otherwise, INCOMING == MIN(ABI_STACK_BOUNDARY, >PREFERRED_STACK_BOUNDARY) because a function can be called via psABI >externally or called locally with PREFERRED_STACK_BOUNDARY. 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 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. (Or just PREFERRED_STACK_BOUNDARY because a boundary less than the ABI's should be rejected during command line processing.) >vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required >by local variables and calling other function. REQUIRED_STACK_ALIGNMENT >== MAX(LOCAL_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY) in case of a >non-leaf function. For a leaf function, REQUIRED_STACK_ALIGNMENT == >LOCAL_STACK_BOUNDARY. Hmm... I think you should define STACK_BOUNDARY as the minimum alignment that ABI requires the stack pointer to keep at all times. ABI_STACK_BOUNDARY should be defined as the stack alignment the ABI requires at function entry. In that case a leaf function's REQUIRED_STACK_ALIGMENT should be MAX(LOCAL_STACK_BOUNDARY, STACK_BOUNDARY). >Because I386 PIC requires BX as GOT pointer and I386 may use AX, DX >and CX as parameter passing registers, there are limited candidates for >this proposal to choose. Current proposal suggests EDI, because it won't >conflict with i386 PIC or regparm. Could you pick a call-clobbered register in cases where one is availale? >// Reserve two stack slots and save return address >// and previous frame pointer into them. By >// pointing new ebp to them, we build a pseudo >// stack for unwinding Hmmm... I don't know much about the DWARF unwind information, but couldn't it handle this case without creating the "pseudo frame"? Or at least be extended so it could? Ross Ridge