From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4954 invoked by alias); 10 Jan 2008 19:00:54 -0000 Received: (qmail 4946 invoked by uid 22791); 10 Jan 2008 19:00:53 -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; Thu, 10 Jan 2008 19:00:31 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 2871B17F506 for ; Thu, 10 Jan 2008 16:54:47 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0AJ0Rki3698764 for ; Thu, 10 Jan 2008 17:00:28 -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 m0AJ0RfH021458 for ; Thu, 10 Jan 2008 17:00:27 -0200 Received: from [9.18.238.70] ([9.18.238.70]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0AJ0RjB021453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jan 2008 17:00:27 -0200 Subject: [RFC] Linux-specific ppc32 ABI From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: gdb-patches@sourceware.org Content-Type: text/plain Date: Thu, 10 Jan 2008 19:00:00 -0000 Message-Id: <1199991624.3343.19.camel@gargoyle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 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/msg00244.txt.bz2 Hi, GDB currently handles stack frame creation when calling inferior functions for SYSV/ppc32 through the ppc_sysv_abi_push_dummy_call(...) method. GDB on Linux/ppc32 relies on this function as well since it doesn't have an explicit implementation in ppc-linux-tdep.c. The problem is that the implementation for ppc_sysv_abi_push_dummy_call(...) has a problem that needs to be fixed, related to the size of float parameters that are meant to be stored in the stack during parameter passing in a function. The question is, would it be safe to assume that SYSV would comply with Linux ABI's especifications for ppc32, so it would only be necessary to change the SYSV implementation, or would it be a better idea to just write new Linux-specific code in ppc-linux-tdep.c? The only difference between these two functions would be the fix for float parameter passing through the stack and the place they're located: "ppc-linux-tdep.c" vs "ppc-sysv-tdep.c". I presume it's better to just write new Linux-specific code in case we need to treat those ABI's differently in the future. What do you think? -- Luis Machado Software Engineer IBM Linux Technology Center