From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8867 invoked by alias); 4 Oct 2006 19:00:39 -0000 Received: (qmail 8849 invoked by uid 22791); 4 Oct 2006 19:00:38 -0000 X-Spam-Check-By: sourceware.org Received: from e1.ny.us.ibm.com (HELO e1.ny.us.ibm.com) (32.97.182.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Oct 2006 19:00:36 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k94J0Ymx023248 for ; Wed, 4 Oct 2006 15:00:34 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k94J0YTW146758 for ; Wed, 4 Oct 2006 15:00:34 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k94J0YS1016174 for ; Wed, 4 Oct 2006 15:00:34 -0400 Received: from linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k94J0YOo016147; Wed, 4 Oct 2006 15:00:34 -0400 Received: from HELLO-009053038156.austin.ibm.com (HELLO-009053038156.austin.ibm.com [9.53.38.156]) by imap.linux.ibm.com (Horde MIME library) with HTTP; Wed, 4 Oct 2006 15:00:34 -0400 Message-ID: <20061004150034.1xgq6l4picg0wgk4@imap.linux.ibm.com> Date: Wed, 04 Oct 2006 19:00:00 -0000 From: janani@linux.ibm.com To: gdb-patches@sourceware.org Cc: pgilliam@us.ibm.com, janani@us.ibm.com Subject: [patch] Pushing Inferior Function Arguments onto Stack on PowerPC64 machines MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00013.txt.bz2 > Is Andrew's comment about the ABI correct, or incorrect? Do you know >> for sure? >> ! /* WARNING: cagney/2003-09-21: As best I can >> ! tell, the ABI specifies that the value should >> ! be left aligned. Unfortunately, GCC doesn't >> ! do this - it instead right aligns even sized >> ! values and puts odd sized values on the >> ! stack. Work around that by putting both a >> ! left and right aligned value into the >> ! register (hopefully no one notices :-^). >> ! Arrrgh! */ > --=20 > Daniel Jacobowitz > CodeSourcery I am new to this, so my interpretation might not be completely=20=20 accurate, but the way I read the note below ( a snippet from the GNU=20=20 GCC Manual about passing function arguments in registers) is that=20=20 since PPC64 is big endian, even though the default is to pad downward=20=20 (i.e. right align), if the size if greater than the size of an int,=20=20 you need to pad upward (left align). ....... FUNCTION_ARG_PADDING (mode, type) If defined, a C expression which determines whether, and in which=20=20 direction, to pad out an argument with extra space. The value should=20=20 be of type enum direction: either upward to pad above the argument,=20=20 downward to pad below, or none to inhibit padding. The amount of padding is always just enough to reach the next=20=20 multiple of FUNCTION_ARG_BOUNDARY; this macro does not control it. This macro has a default definition which is right for most=20=20 systems. For little-endian machines, the default is to pad upward. For=20=20 big-endian machines, the default is to pad downward for an argument of=20=20 constant size shorter than an int, and upward otherwise. ..... Janani Janakiraman