From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6826 invoked by alias); 25 Jan 2008 16:06:40 -0000 Received: (qmail 6812 invoked by uid 22791); 25 Jan 2008 16:06:39 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jan 2008 16:06:01 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id A738117F75D for ; Fri, 25 Jan 2008 13:59:40 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0PG5uHI3903556 for ; Fri, 25 Jan 2008 14:05:56 -0200 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0PG5ta5019352 for ; Fri, 25 Jan 2008 14:05:55 -0200 Received: from [9.18.238.41] (dyn531774.br.ibm.com [9.18.238.41]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0PG5tCT019349; Fri, 25 Jan 2008 14:05:55 -0200 Subject: Re: [RFC] Linux-specific ppc32 ABI From: Thiago Jung Bauermann To: luisgpm@linux.vnet.ibm.com Cc: Daniel Jacobowitz , Joel Brobecker , gdb-patches@sourceware.org In-Reply-To: <1200086736.26270.35.camel@gargoyle> References: <1199991624.3343.19.camel@gargoyle> <20080111060629.GC12954@adacore.com> <1200066920.26270.9.camel@gargoyle> <20080111155733.GA3240@caradoc.them.org> <1200086736.26270.35.camel@gargoyle> Content-Type: text/plain Date: Fri, 25 Jan 2008 16:13:00 -0000 Message-Id: <1201277155.11950.134.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00612.txt.bz2 On Fri, 2008-01-11 at 19:25 -0200, Luis Machado wrote: > > > > How about an extra flag inside the gdbarch_tdep structure that > > > > you'll be using inside the push dummy call? It would be a shame > > > > duplicate this function when most of it is common. > Actually, we won't need to go through the flag. I've checked and the > PPC/Linux ABI conforms with the PPC/SysV ABI regarding Calling Sequences > and the Stack layout. > The SysV ABI says we should promote exceeding float parameters (the ones > that should go to the stack) to double, and store then with 8 bytes > alignment in the stack. > GCC (XLC as well) doesn't promote floats to doubles and does not align > them to 8 bytes in the stack. Actually, it just aligns the prototyped > float parameters to 4 bytes in the stack. > > This is something that needs to be improved in the ABI text. > > The patch follows, with a minor change in the ABI handling for PPC32 and > a testcase Thiago wrote to verify the problem. > > Comments? Ping? It would be nice if someone could test this patch in other systems which use the SysV ppc32 ABI, to see if they actually implement what is in the ABI specification or if they also do what Linux actually does. If the former, this patch could go in. If the latter, we could use the suggested flag in gdbarch_tdep to restrict this fix only to Linux. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center