From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27189 invoked by alias); 15 Jan 2008 17:40:31 -0000 Received: (qmail 27181 invoked by uid 22791); 15 Jan 2008 17:40:31 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Jan 2008 17:40:02 +0000 Received: from mailhub1.br.ibm.com (unknown [9.18.232.109]) by igw3.br.ibm.com (Postfix) with ESMTP id 7D2BF39002F for ; Tue, 15 Jan 2008 15:31:48 -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 m0FHdnbJ3993818 for ; Tue, 15 Jan 2008 15:39:51 -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 m0FHdn3k016677 for ; Tue, 15 Jan 2008 15:39:49 -0200 Received: from [9.18.238.41] ([9.18.238.41]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0FHdnHw016674; Tue, 15 Jan 2008 15:39:49 -0200 Subject: Re: [RFA] Fix float argument passing in inferior function calls for ppc64 From: Thiago Jung Bauermann To: Mark Kettenis Cc: gdb-patches@sourceware.org In-Reply-To: <200801151443.m0FEhxN3021953@brahms.sibelius.xs4all.nl> References: <1200400434.3158.64.camel@localhost.localdomain> <200801151443.m0FEhxN3021953@brahms.sibelius.xs4all.nl> Content-Type: text/plain Date: Tue, 15 Jan 2008 17:40:00 -0000 Message-Id: <1200418789.3158.71.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/msg00357.txt.bz2 On Tue, 2008-01-15 at 15:43 +0100, Mark Kettenis wrote: > > The 64-bit PowerPC ELF ABI version 1.9 says that "single precision > > floating point values are mapped to the second word in a single > > doubleword". The ppc64_sysv_abi_push_dummy_call function in > > ppc-sysv-tdep.c, however, implements version 1.7 of the ABI which says > > that they should go in the first doubleword. > > Aren't ABI changes fun? Heh. :-) > Is the first word used for anything in the new ABI? If not, you could > support both ABIs by copying the value into both the first and the > second word. Great idea. I will resend the patch using that approach then. > > Because of this, if you are calling a function with many arguments and > > some need to be passed on the stack, GDB will get it wrong for 32-bit > > floats. This is why in Linux/ppc64 GDB fails the "Call function with > > many float arguments" test posted here: > > > > http://sourceware.org/ml/gdb-patches/2008-01/msg00291.html > > > > This patch fixes the test. It makes GDB pass 32-bit floats in the second > > word when passing them in the stack as stated in the current ABI. > > > > I didn't touch the code which writes the float to a general register in > > the first word because I'm not sure how to test it. It is probably > > related to soft-float, I guess. > > Actually, it may be related to varargs. Or perhaps it is a leftover > from the 32-bit ABI code that was copied. I'll play with varargs and see if I can trigger that code and create a test for it. > > Tested on Linux/ppc64 with no regressions. I believe this will also fix > > other operating systems supported by GDB on ppc64 since they use the > > same push_dummy_call implementation (assuming they also follow the > > current SysV ABI), but I don't have the means to test them either. > > > > Maybe someone could test the patch and the testcase in *BSD? Luis' patch > > which has the testcases would also need this testing. > > There's no 64-bit OpenBSD/powerpc port; we only run on Apple hardware > and we run the G5 machines in 32-bit mode. > > It doesn't look like NetBSD and FreeBSD have a working 64-bit powerpc > port either. Ok, good to know that. > I'm fairly certain Linux/ppc64 used the old ABI for a while. Are you > certain GDB doesn't need to support any people running those older > installs anymore? No, I'm not actually... Writing in both words should resolve this. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center