Re: [PATCH] config.bfd: Adding tic4x-*-rtems

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Ralf Corsepius wrote:
> 
> Am Fre, 2003-06-20 um 10.33 schrieb Nick Clifton:
> > Hi Ralf,
> >
> > > I would like to propose tic4x-*-rtems to be added to config.bfd (2.14 +
> > > mainline, cf. patch against 2.14-branch below)
> >
> >
> > > 2003-06-20  Ralf Corsepius  <corsepiu@faw.uni-ulm.de>
> > >
> > >     * config.bfd: Add tic4x-*-rtems*.
> >
> > Approved and applied.  (Although I just added the new entry on the
> > same line as the current (ti)c4x-coff entry.  I saw no particular
> > reason to split it up over multiple lines.
> ;)
> 
> > One question though:
> >
> > > +  c4x-*-*coff* | \
> > > +  tic4x-*-*coff* | tic4x-*-rtems*)
> >
> > Shouldn't there also be support for a "c4x-*-rtems*" target ?
> 
> IMHO, there should not be any c4x-* target (I.e. IMHO, references to
> c4x-* should be removed from binutils, because the c4x-*-target is dead
> for binutils and gcc and has been replaced by tic4x-*.)
> 
> Therefore, instead, binutils should better complain and abort if being
> configured for c4x-*.

My understanding is that c4x-* was only usable with the set of patches 
Michael Hayes' distributed.  They haven't been updated in a long time
so I don't mind if c4x-* is purged as well.  There can't be that many
users. 

However, if there is a real difference between what c4x-* did and
tic4x-* is intended to do, then the distinction may be important. 
Right now, I don't see that it is.  It is just a matter of the
first porting effort choosing a naming style that subsequent TI DSP
ports didn't.  It is now in the minority and can't be used by many 
people.

> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985