From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27919 invoked by alias); 14 May 2002 13:51:59 -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 27899 invoked from network); 14 May 2002 13:51:55 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 14 May 2002 13:51:55 -0000 Received: from localhost.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id GAA11015; Tue, 14 May 2002 06:51:48 -0700 (PDT) Received: by localhost.redhat.com (Postfix, from userid 469) id 16CAC10FC9; Tue, 14 May 2002 09:51:16 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15585.5715.936570.74188@localhost.redhat.com> Date: Tue, 14 May 2002 06:51:00 -0000 To: Nick Clifton Cc: Elena Zannoni , thorpej@wasabisystems.com, binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf* In-Reply-To: References: <20020511115603.W3435@dr-evil.shagadelic.org> <20020513082324.R3435@dr-evil.shagadelic.org> <15584.11203.728429.774659@localhost.redhat.com> X-SW-Source: 2002-05/txt/msg00536.txt.bz2 Nick Clifton writes: > Hi Elena, > > > > + shle-*-netbsdelf*) > > > + targ_defvec=bfd_elf32_shlnbsd_vec > > > + targ_selvecs="bfd_elf32_shnbsd_vec shcoff_vec shlcoff_vec" > > > +#ifdef BFD64 > > > + targ_selvecs="${targ_selvecs} bfd_elf32_sh64_vec bfd_elf32_sh64l_vec bfd_elf64_sh64_vec bfd_elf64_sh64l_vec" > > > +#endif > > > + ;; > > > sh*le-*-netbsdelf*) > > > targ_defvec=bfd_elf32_shlnbsd_vec > > > targ_selvecs="bfd_elf32_shnbsd_vec shcoff_vec shlcoff_vec" > > > Wouldn't the same change be required to build sh*le-*-netbdself* ? > > Err, no. I think that Jason's point was that support for the SH64 > architecture was only desireable if the configure target was "sh" and > not "sh3" or "sh4". Presumably "sh" is intended to mean "any SH > processor" whereas "sh3" means "only the SH3 processor". Yes, I realized that. > > > The tdep gdb file is going to be built for all the sh targets. And > > that file requires the sh64 disassembly functions. > > In which case there may well be a problem. As it stands configuring > BFD as, eg, sh3-elf will not bring in the sh64 architecture or > disassembly functions. Can the tdep file be made conditional on the > SH architecture specified on the configure command line ? > No, it wouldn't be accepted. We are going towards unifying all the targets for a given architecture, so that we can switch at runtime with multiarch. I mean, it is not technically impossible, but it is philosophically inconsistent with where gdb is going nowadays. We are even going to build multiple architectures together, like sh and ppc, in a single executable. As a matter of fact I had such defines when I first submitted the port, and I removed them. Elena > Cheers > Nick