From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24651 invoked by alias); 24 Oct 2003 14:55:20 -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 24644 invoked from network); 24 Oct 2003 14:55:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 24 Oct 2003 14:55:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AD3LP-0006lx-VR; Fri, 24 Oct 2003 10:55:15 -0400 Date: Fri, 24 Oct 2003 14:55:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc,rfa:ppc64] Add osabi wildcard support Message-ID: <20031024145515.GA25732@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3F986371.9060708@redhat.com> <3F9937AF.4010201@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9937AF.4010201@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00731.txt.bz2 On Fri, Oct 24, 2003 at 10:31:11AM -0400, Andrew Cagney wrote: > >and the second is to explicitly register both of these architecture > >variants vis: > > > > gdbarch_register_osabi (bfd_arch_powerpc, bfd_mach_ppc, ... > > gdbarch_register_osabi (bfd_arch_powerpc, bfd_mach_ppc64, ... > > plus, I believe, either > + gdbarch_register_osabi (bfd_arch_rs6000, bfd_mach_rs6k); > or: > + gdbarch_register_osabi (bfd_arch_powerpc, bfd_mach_rs6k); > > Per this post: > http://sources.redhat.com/ml/binutils/2003-10/msg00543.html > rs6000:6000 isn't considered compatible with the generic PPC, and hence > the OSABI code couldn't find a match. That lead to the warning. Excuse the rambling. I always have to type this out to figure out which way it goes. >From bfd/cpu-powerpc.c, I see: case bfd_arch_rs6000: if (a->mach == bfd_mach_ppc) return a; Let's take: ppc = {bfd_arch_powerpc, bfd_mach_ppc}; ppcrs6k = {bfd_arch_powerpc, bfd_mach_rs6k}; rs6k = {bfd_arch_rs6000, bfd_mach_rs6k}; We call default_arch->compatible (default_arch, handler_arch). That's "can the default architecture run code for the architecture being handled". We call rs6k->compatible(rs6k, ppc). That's "an rs6k can run code written for a generic powerpc", which returns false. The only true one is rs6k->compatible(rs6k, rs6k) or rs6k->compatible(rs6k, ppcrs6k): an rs6k can not run generic ppc code but it can run ppc/rs6k code. So your suggestion seems right. Confusingly, a generic ppc can run code for any rs6k according to the compatible function. That threw me a loop. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer