From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9707 invoked by alias); 4 Oct 2006 19:54:43 -0000 Received: (qmail 9697 invoked by uid 22791); 4 Oct 2006 19:54:43 -0000 X-Spam-Check-By: sourceware.org Received: from e3.ny.us.ibm.com (HELO e3.ny.us.ibm.com) (32.97.182.143) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Oct 2006 19:54:40 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k94JsZR0017511 for ; Wed, 4 Oct 2006 15:54:35 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k94JsZSH280918 for ; Wed, 4 Oct 2006 15:54:35 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k94JsYRE029324 for ; Wed, 4 Oct 2006 15:54:34 -0400 Received: from linux.ibm.com (imap.raleigh.ibm.com [9.37.253.145]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k94JsYlB029289; Wed, 4 Oct 2006 15:54: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:54:34 -0400 Message-ID: <20061004155434.jjq724t40kwosws8@imap.linux.ibm.com> Date: Wed, 04 Oct 2006 19:54:00 -0000 From: janani@linux.ibm.com To: gdb-patches@sourceware.org Cc: janani@us.ibm.com, drow@false.org Subject: Re: [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/msg00017.txt.bz2 Sorry about the email address goofup. Am trying to use a new account=20=20 so that HTML tags don't get in the way. Have to figure out a way to=20=20 enable me to receive email at this address. My other external email=20=20 address is janani@us.ibm.com From reading the PPC64 Platform ABI at http://www.freestandards.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html ( see section 3.1.7) it appears that on Big Endian machines, values are left aligned. But looks like GCC has different rules and=20=20 right aligns the values which are put on the registers. This matches Andrew Cagney comment in the code, that says=20=20 that ABI specifies that the values should be left aligned. But like I said in my earlier note, GCC=20=20 appears to want the values to be right aligned. Would appreciate another set of eyes looking at it as=20=20 I don't have too much experience in this area. Daniel Jacobowitz wrote on 10/04/2006 02:10:56 PM: > On Wed, Oct 04, 2006 at 03:00:34PM -0400, janani@linux.ibm.com wrote: > > 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=20=20 > downward > (i.e. right align), if the size if greater than the size=20=20 > of an int, > you need to pad upward (left align). > > You're trying to answer the wrong question :-) > > It's not "what does GCC do", but "what does the platform ABI say we > should do". Is GCC conforming to the ABI? Is the ABI wrong, or out of > date, or was Andrew's reading of it wrong, or... > > There could be a real problem here, so it's important that we > understand what is _supposed_ to happen before we make a change. > If GCC is violating the ABI, then either GCC or the ABI may need to be > updated. If GDB is misinterpreting the ABI, then just GDB needs to be > changed. > > --=20 > Daniel Jacobowitz > CodeSourcery > ! /* 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! */ > ! /* Left aligned (8 byte values such as pointers > ! fill the buffer). */ > ! memcpy (regval, val + byte, len); > ! /* Right aligned (but only if even). */ > ! if (len =3D=3D 1 || len =3D=3D 2 || len =3D=3D 4) > ! memcpy (regval + tdep->wordsize - len, Janani Janakiraman