From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10301 invoked by alias); 13 Jun 2003 06:17:43 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10232 invoked from network); 13 Jun 2003 06:17:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Jun 2003 06:17:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5D6HgH00404 for ; Fri, 13 Jun 2003 02:17:42 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5D6HfI16757; Fri, 13 Jun 2003 02:17:41 -0400 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5D6Hee00521; Fri, 13 Jun 2003 02:17:40 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5D6HZH00460; Thu, 12 Jun 2003 23:17:35 -0700 Date: Fri, 13 Jun 2003 06:17:00 -0000 From: Kevin Buettner Message-Id: <1030613061734.ZM459@localhost.localdomain> In-Reply-To: Richard Henderson "Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method" (Jun 12, 9:48pm) References: <1030611224249.ZM27163@localhost.localdomain> <20030613044807.GF30567@redhat.com> To: Richard Henderson , Jim Blandy Subject: Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method Cc: Kevin Buettner , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00459.txt.bz2 On Jun 12, 9:48pm, Richard Henderson wrote: > On Thu, Jun 12, 2003 at 04:11:31PM -0500, Jim Blandy wrote: > > + /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux. > > Not just Linux, but everywhere else as well. > > Indeed, the 64-bit ABI lifts this from 32-bit AIX, so it seems > like this function should be generic in the ppc backend somewhere. It does exist in rs6000-tdep.c (as rs6000_convert_from_func_ptr_addr) and I believe that that function would work for 64-bit PPC Linux also. So, an alternate approach (to what Jim did) is to export rs6000_convert_from_func_ptr_addr() via ppc-tdep.h and then register it in ppc-linux-tdep.c. That may be preferable in this case since this function is relatively simple and it could be argued that if there is a bug in the code, it would likely be a bug for both ABIs. Fixing such a bug in one location is preferable to having to fix it in multiple locations. OTOH, there's been a recent trend towards separating this kind of thing out for different ABIs. E.g, look at all of push_argument variants in mips-tdep.c. At one time, not too long ago, all of the push_argument() variants were rolled into one big function. (There are some other MIPS related examples that are somewhat less extreme.) The reason that this was done is so that fixes may be made to the support of a given ABI without having to worry about breaking the support for the other ABIs. There are pros and cons to each approach and, for this case, I don't see a clear cut winner. Since Jim is in the code at the moment, and has been giving it a lot of thought, I'll leave it up to him to decide on the best course of action. Kevin