This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/RFA] Include sh64 support for shle-*-netbsdelf*


Alexandre Oliva writes:
 > 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.
 > 

Ah, actually at the moment there is just sh-*-linux*.  I think it is
just a configury oversight.  JasonT added sh*-*-netbsdelf* for
instance, which should catch all the instances. I think there should
be a corresponding sh*-*-linux*.
Groan, how many other is gdb missing?


 > 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.
 > 

Have a look at:
http://sources.redhat.com/gdb/papers/multi-arch

 > 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?
 > 

This is where we (can't take credit here, actually, it's mostly
Andrew) are taking gdb. Andrew has built a gdb which inlcuded 2
completely different architectures. I believe it was mn10300 and d10v.
There needs to be some more (a lot more) gdb internals cleanup, but
that will be true multiarch. Probably building all the targets would
be a bit too much, in practice, but it would become possible to
combine any of the architectures.


 > 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 :-)
 > 

I think these exchanges are really really useful, actually.


Elena


 > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]