From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11392 invoked by alias); 11 Jan 2008 15:55:51 -0000 Received: (qmail 11383 invoked by uid 22791); 11 Jan 2008 15:55:50 -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, 11 Jan 2008 15:55:28 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw2.br.ibm.com (Postfix) with ESMTP id 8AC0117F43F for ; Fri, 11 Jan 2008 13:49:41 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0BFtPuu4014112 for ; Fri, 11 Jan 2008 13:55:25 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0BFtOxM024584 for ; Fri, 11 Jan 2008 13:55:24 -0200 Received: from [9.18.238.70] ([9.18.238.70]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0BFtObM024575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jan 2008 13:55:24 -0200 Subject: Re: [RFC] Linux-specific ppc32 ABI From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20080111060629.GC12954@adacore.com> References: <1199991624.3343.19.camel@gargoyle> <20080111060629.GC12954@adacore.com> Content-Type: text/plain Date: Fri, 11 Jan 2008 15:55:00 -0000 Message-Id: <1200066920.26270.9.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/msg00272.txt.bz2 > Assuming a difference in ABI does exist: Yes, there are a few differences between what the SYSTEM V ABI says and what Linux actually does. But most of the Linux specs follow the SYSTEM V ABI. > 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. Yes. This would work, but putting linux specific code inside the ppc-sysv-tdep.c file doesn't look quite right. But if there isn't a better way of doing this, should be OK. Regards, -- Luis Machado Software Engineer IBM Linux Technology Center