From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22198 invoked by alias); 18 Jul 2003 14:19:33 -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 22158 invoked from network); 18 Jul 2003 14:19:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 18 Jul 2003 14:19:32 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19dW50-0004FF-00; Fri, 18 Jul 2003 10:19:26 -0400 Date: Fri, 18 Jul 2003 14:19:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , kewarken@qnx.com, gdb-patches@sources.redhat.com Subject: Re: [ping] Re: [Patch] arch recognition fix for osabi.c Message-ID: <20030718141926.GA16249@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , kewarken@qnx.com, gdb-patches@sources.redhat.com References: <08c201c334e6$ccb8c750$0202040a@catdog> <20030617155147.GA25280@nevyn.them.org> <08d801c334ea$23fd99c0$0202040a@catdog> <20030619190853.GA25755@nevyn.them.org> <113c01c347bd$ba454a00$0202040a@catdog> <200307111626.h6BGQi3W033834@elgar.kettenis.dyndns.org> <3F1800A2.90605@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1800A2.90605@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00339.txt.bz2 On Fri, Jul 18, 2003 at 10:13:54AM -0400, Andrew Cagney wrote: > >Apparently this doesn't work for MIPS, since BFD declares different > >processors (which it calls "machines") to be incompatible. I'm not > >quite familiar with MIPS, but I suppose this is not quite true, but > >that the various MIPS processors cannot be mapped on a one-dimensional > >quantity that expresses the features of the various CPU's. That could > >be a valid reason why the MIPS "compatibility function" is written the > >way it is. Perhaps it can be improved? If so, I think that's the way > >to go. Otherwise, I think you should register for all CPU types that > >you support. > > Can, to make life less painful, a wild card (-1 safe?) be added? Now that's a good idea, simple and safe. I still believe (see my last message in this thread) that the problem is one in osabi.c; that a return of either of its arguments from the compatibility function should be accepted. But if a wildcard is preferred then that would solve the problem too, and I just want the problem solved... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer