From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32741 invoked by alias); 11 Jul 2003 16:27:27 -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 32734 invoked from network); 11 Jul 2003 16:27:24 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.212) by sources.redhat.com with SMTP; 11 Jul 2003 16:27:24 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h6BGQjaM003791; Fri, 11 Jul 2003 18:26:45 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h6BGQit3033837; Fri, 11 Jul 2003 18:26:44 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h6BGQi3W033834; Fri, 11 Jul 2003 18:26:44 +0200 (CEST) Date: Fri, 11 Jul 2003 16:27:00 -0000 Message-Id: <200307111626.h6BGQi3W033834@elgar.kettenis.dyndns.org> From: Mark Kettenis To: kewarken@qnx.com CC: drow@mvista.com, gdb-patches@sources.redhat.com In-reply-to: <113c01c347bd$ba454a00$0202040a@catdog> (kewarken@qnx.com) Subject: Re: [ping] Re: [Patch] arch recognition fix for osabi.c References: <08c201c334e6$ccb8c750$0202040a@catdog> <20030617155147.GA25280@nevyn.them.org> <08d801c334ea$23fd99c0$0202040a@catdog> <20030619190853.GA25755@nevyn.them.org> <113c01c347bd$ba454a00$0202040a@catdog> X-SW-Source: 2003-07/txt/msg00242.txt.bz2 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. 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. Mark