This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: c4x - TMS320C30-40



Ralf Corsepius wrote:
> 
> Am Mit, 2003-06-04 um 18.40 schrieb Joel Sherrill:
> > "Svein E. Seldal" wrote:
> > >
> > > I have taken the liberty to continue this discussion in the public forum
> > > of the binutils list...
> >
> > Fine by me.
> >
> > > Joel Sherrill wrote:
> > > > Well I can report that is builds.  There is a problem in the top level
> > > > config.sub which breaks tic4x-rtems and c4x-rtems.  Neither is in the
> > > > master list of CPUs (variable name basic_machine) around line 223.
> > > > Worse, later (line 916) c4x* (notice the *) is always mapped to
> > > > tic4x-unknown.
> > > > I deleted the "*" on line 916 and added c4x and tic4x to the list of
> > > > basic
> > > > machines and it now recognizes tic4x-rtems and c4x-rtems.  I am not
> > > > 100% sure of the fix but know that ./config.sub gives me the answer I
> > > > expect for the following cases:
> > > >
> > > > c4x-coff
> > > > c4x-elf
> > > > c4x-rtems
> > > > tic4x-coff
> > > > tic4x-elf
> > > > tic4x-rtems
> > > >
> > > > Before my mods tic4x-* --> tic4x-coff and ditto for c4x.
> > >
> > > Well this is a kind of issue. First of all, config.sub should report
> > > 'tic4x' when you input 'c4x'.
> I do not agree on this.
> 
> Why not keeping them separate? c4x is one thing, tic4x is a different
> one. If people want to use your C40 ports, just tell them to use
> tic4x-*.

I am happy with binutils and gcc using the underlying tic4x port.  The 
c4x port was a collection of patches that were somewhat maintained way 
back when.  As I udnerstand it, the tic4x is the a heavily updated
version of the old c4x support and officially merged. I don't want the 
old port really -- just the old name to work.

> > >  This is a part of the depreciated name
> > > thing. It enables people to still use the c4x as a targetname for the
> > > tic4x, because the 'c4x' name does not work in the binutils.
> IMO, then, binutils (!) should not accept "c4x".

Agreed.  If the community wants to kill the c4x name, then so be it.
But IMO it isn't right to do this and leave the gcc/config directory
named c4x.  At this point, I think both names should just do the same
thing.  However that is accomplished is fine by me.

But I see Ralf's point, if config.sub makes them the same, then it
has removed the opportunity for any other autoconf-ed program to
treat them differently.  So the question is, 

  "Are c4x* and tic4x* the same targets for all autoconf'ed tools?"

If the answer is yes, then make them the same in config.sub.  If no,
then the answer out of config.sub must be different.

> config.sub is much more general than binutils/gcc and therefore must
> accept any target-triple anybody thinks is useful somewhere.
> People (Admitted, probably very few) have been and are using c4x* for
> their proprietary purposes (eg. RTEMS does still support the "c4x"
> targets), therefore you (rsp. binutils) is not in a position to change
> this.

Right.  But this is the first official release with enough c4x/tic4x
support to matter.  We can set the precedent now.  RTEMS is very likely
the only other autoconf'ed program that has explicit tic4x/c4x support.

So I went for the simple solution -- tic4x* and c4x* are the same
things.

> > I should have been more formal about the output of config.sub.  The
> > output is the same with the config.sub shipped with gcc 3.3
> > and binutils 2.13.91.
> 
> > bash-2.05$ sh -x /tmp/j1
> > + ./config.sub tic4x-coff
> > tic4x-unknown-coff
> > + ./config.sub tic4x-elf
> > tic4x-unknown-coff
> > + ./config.sub tic4x-rtems
> > tic4x-unknown-coff
> > + ./config.sub c4x-coff
> > tic4x-unknown-coff
> > + ./config.sub c4x-elf
> > tic4x-unknown-coff
> > + ./config.sub c4x-rtems
> > tic4x-unknown-coff
> >
> > No matter what you provide to config.sub, you end up with tic4x-coff.
> 
> You have just discovered, why I introduced a hacked config.sub to RTEMS.
> 
> My proposal: Keep tic4x and c4x separate in config.sub.
> 
> Applications (binutils, gcc, newlib, RTEMS) then can deal with these
> target_cpu's at their will.

I believe gcc does this already.  config.gcc recognizes them both.  That
makes it up to binutils to alias them together. If this is the decision.


> 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


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