Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Nick Clifton <nickc@cambridge.redhat.com>
Cc: Elena Zannoni <ezannoni@redhat.com>,
	thorpej@wasabisystems.com, binutils@sources.redhat.com,
	gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf*
Date: Tue, 14 May 2002 08:20:00 -0000	[thread overview]
Message-ID: <ord6vy7o58.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <m3u1pag5zn.fsf@north-pole.nickc.cambridge.redhat.com>

On May 14, 2002, Nick Clifton <nickc@cambridge.redhat.com> 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


  parent reply	other threads:[~2002-05-14 15:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-11 11:56 Jason R Thorpe
2002-05-13  1:48 ` Nick Clifton
2002-05-13  8:23   ` Jason R Thorpe
2002-05-13 10:35     ` Nick Clifton
2002-05-13 15:13       ` Elena Zannoni
2002-05-13 14:28         ` Jason R Thorpe
2002-05-13 15:13           ` Elena Zannoni
2002-05-14  1:50         ` Nick Clifton
2002-05-14  6:51           ` Elena Zannoni
2002-05-14  7:27             ` Nick Clifton
2002-05-14  8:17               ` Elena Zannoni
     [not found]                 ` <m3offha19r.fsf@north-pole.nickc.cambridge.redhat.com>
     [not found]                   ` <3CE2B34F.EAAEF3F8@superh.com>
     [not found]                     ` <15587.63152.235989.94659@localhost.redhat.com>
2002-05-17  5:40                       ` print_insn_sh cleanup Joern Rennecke
2002-05-17  6:54                         ` Elena Zannoni
2002-05-17  7:39                           ` Joern Rennecke
2002-05-20  4:22                             ` Alexandre Oliva
2002-05-20  6:29                               ` Joern Rennecke
2002-05-20  6:57                                 ` Hans-Peter Nilsson
2002-05-14  8:20               ` Alexandre Oliva [this message]
2002-05-14  8:38                 ` [PATCH/RFA] Include sh64 support for shle-*-netbsdelf* Elena Zannoni
2002-05-14  8:46                 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ord6vy7o58.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=binutils@sources.redhat.com \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=nickc@cambridge.redhat.com \
    --cc=thorpej@wasabisystems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox