From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8055 invoked by alias); 25 Dec 2002 00:34:32 -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 8048 invoked from network); 25 Dec 2002 00:34:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 25 Dec 2002 00:34:31 -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 gBP07cB22034 for ; Tue, 24 Dec 2002 19:07:38 -0500 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 gBP0YJa28221; Tue, 24 Dec 2002 19:34:19 -0500 Received: from localhost.localdomain (vpn50-19.rdu.redhat.com [172.16.50.19]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gBP0YJL13393; Tue, 24 Dec 2002 19:34:19 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id gBP0YD628149; Tue, 24 Dec 2002 17:34:13 -0700 Date: Tue, 24 Dec 2002 19:25:00 -0000 From: Kevin Buettner Message-Id: <1021225003413.ZM28148@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets" (Dec 24, 2:40pm) References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> <1021224062810.ZM26995@localhost.localdomain> <20021224145304.GA29615@nevyn.them.org> <1021224192935.ZM27391@localhost.localdomain> <20021224194011.GA2004@nevyn.them.org> To: Daniel Jacobowitz Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00674.txt.bz2 On Dec 24, 2:40pm, Daniel Jacobowitz wrote: [...] > > I found it necessary to change the osabi registration (in mips-linux-tdep.c) > > from: > > > > gdbarch_register_osabi (bfd_arch_mips, 0, GDB_OSABI_LINUX, > > mips_linux_init_abi); > > > > to: > > > > for (arch_info = bfd_lookup_arch (bfd_arch_mips, 0); > > arch_info != NULL; > > arch_info = arch_info->next) > > { > > gdbarch_register_osabi (bfd_arch_mips, arch_info->mach, GDB_OSABI_LINUX, > > mips_linux_init_abi); > > } > > > > I'm not entirely happy with this change, but I see no way around it > > due to the recent changes to osabi.c. (I'm open to suggestions for > > better ways to do it...) > > OK, that's a problem. In fact it's disgusting... A mach value of 0 is > always supposed to mean "default", if I remember my BFD correctly. Has > the change to pass a machine of 0 broken osabi support for anything > that sets a machine? It looks that way. I wonder if Mark made a mistake in his recent change to gdbarch_init_osabi(), specifically in the following code: for (handler = gdb_osabi_handler_list; handler != NULL; handler = handler->next) { if (handler->osabi != osabi) continue; /* Check whether the machine type and architecture of the handler are compatible with the desired machine type and architecture. NOTE: kettenis/20021027: There may be more than one machine type that is compatible with the desired machine type. Right now we simply return the first match, which is fine for now. However, we might want to do something smarter in the future. */ compatible = arch_info->compatible (arch_info, handler->arch_info); if (compatible == handler->arch_info) { (*handler->init_osabi) (info, gdbarch); return; } } For MIPS, the compatible() function is defined as follows: static const bfd_arch_info_type * mips_compatible (a, b) const bfd_arch_info_type *a; const bfd_arch_info_type *b; { if (a->arch != b->arch) return NULL; /* Machine compatibility is checked in _bfd_mips_elf_merge_private_bfd_data. */ return a; } So... the first argument is returned when the ``arch'' fields are the same, and NULL otherwise. Thus, for MIPS, the following bit of code: compatible = arch_info->compatible (arch_info, handler->arch_info); if (compatible == handler->arch_info) ... means the same as: if (arch_info == handler->arch_info) ... which seems overly restrictive and not at all in the spirit of the comment preceding that bit of code. Kevin