From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28110 invoked by alias); 14 May 2002 15:20:02 -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 28084 invoked from network); 14 May 2002 15:20:00 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 14 May 2002 15:20:00 -0000 Received: from free.redhat.lsd.ic.unicamp.br (vpn3-4.sfbay.redhat.com [172.16.25.4]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g4EFIRv23444; Tue, 14 May 2002 08:18:28 -0700 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g4EFJWp03378; Tue, 14 May 2002 12:19:32 -0300 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* References: <20020511115603.W3435@dr-evil.shagadelic.org> <20020513082324.R3435@dr-evil.shagadelic.org> <15584.11203.728429.774659@localhost.redhat.com> <15585.5715.936570.74188@localhost.redhat.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Tue, 14 May 2002 08:20:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-05/txt/msg00540.txt.bz2 On May 14, 2002, Nick Clifton wrote: > Hi Elena, [snip] >> 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. > Hmm, OK - in which case would it be acceptable to say that in order to > obtain GDB support an SH toolchain should be configured as "sh-elf" > and not "sh3-elf" even if the intended default processor is the SH3 ? > ie that configurations such as "sh3-elf" are becoming obsolete and > will one day be removed ? This would be a bad idea. Consider, for example, sh3-linux-gnu, where you *really* have to configure at least glibc with sh3-linux-gnu (because glibc can't be multilibbed). Ideally, you should be able to configure everything with the same triplet. It wouldn't be the end of the world if glibc required a different configure triplet, but I guess the GNU/Linux/SH folks would be annoyed if they couldn't have a config.guess that was enough to build all of their tools. I.e., at least sh3-*-linux-gnu should remain supported by GDB. Not that care strongly whether sh3-linux-gnu includes SH64 bits or not; I just thought I'd point this out before we take a step before realizing one of the consequences. I still have the impression that having the GDB SH configuration forcibly bring in SH64 bits too is not the right way to do multi-arching. OTOH, it's not like I know much about multi-arching anyway, but in my conception of a perfect world, it would be possible to enable or disable SH64 support independently from SH support, just like it would be nice to be able to, say, strip out the Thumb-support bits from an ARM-targeted toolchain, when you won't ever want to use it with Thumb-capable processors. But then, the only justifications for this feature would be toolchain build time and size, hardly an issue these days. It's not like stripping bits out would benefit the toolchain performance. But then, why don't we always --enable-targets=all? Yeah, it's clear I'm confused. I almost deleted this message before posting it, but I ended up deciding to post it. Hope it can at least get us all on the same page :-) Cheers, -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer