From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2824 invoked by alias); 11 Jul 2003 16:32:44 -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 2804 invoked from network); 11 Jul 2003 16:32:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Jul 2003 16:32:43 -0000 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19b0ot-0007Ld-00; Fri, 11 Jul 2003 12:32:27 -0400 Date: Fri, 11 Jul 2003 16:32:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: kewarken@qnx.com, gdb-patches@sources.redhat.com Subject: Re: [ping] Re: [Patch] arch recognition fix for osabi.c Message-ID: <20030711163227.GA28063@nevyn.them.org> Mail-Followup-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307111626.h6BGQi3W033834@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00243.txt.bz2 On Fri, Jul 11, 2003 at 06:26:44PM +0200, Mark Kettenis wrote: > From: "Kris Warkentin" > Date: Fri, 11 Jul 2003 11:04:29 -0400 > > Mark, Daniel had suggested that you were the end of the line as far as > approving this change. > > Thread starts here: > http://sources.redhat.com/ml/gdb-patches/2003-06/msg00562.html > > Hmm, I folloed that thread, and I have some things to say about it. I > just never did :-(. > > The code is deliberately written the way it is. The idea is that for > each CPU architecture we have a number of processors. Some of these > are compatible with each other. Others aren't. The trick is to find > the ISA that is most compatible. Most processor families out there > are backwards compatible, which basically means that a new processor > is based on ISA of its predecessor and adds some functionality to > that. For processor families that work like that, > bfd_default_compatible does the right thing, and the code in > gdbarch_init_osabi selects an OSABI/ISA that's a subset of the desired > ISA. > > 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. It doesn't declare different machines to be incompatible. Take another look at mips_compatible; it is actually more lenient than the default. But it _always_ returns a, and osabi.c expects it to return b. I suppose that we could change mips_compatible to return the subset type if one has mach == 0. But even the default doesn't do that right now. > One could argue that if one registers a handler for the "default > machine" that this should apply for all machines within an > architecture, but that breaks down for architectures that support both > 32-bit and 64-bit machines. Which is why the word size is checked separately in bfd_default_compatible. mips_compatible is a whole other kettle of worms. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer