This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: c4x - TMS320C30-40
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- To: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Cc: "Svein E. Seldal" <Svein dot Seldal at solidas dot com>, Binutils List <binutils at sources dot redhat dot com>
- Date: 04 Jun 2003 20:09:28 +0200
- Subject: Re: c4x - TMS320C30-40
- Organization: FAW Ulm
- References: <EF5112993A929342824EAE9F96D28F221B8D29@RDINT4> <3EDB6F0D.48428D10@OARcorp.com> <3EDC8C75.6030005@solidas.com> <3EDDFEC6.5A1E4873@OARcorp.com> <3EDE1682.7090502@solidas.com> <3EDE210F.8AF715F1@OARcorp.com>
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-*.
> > 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".
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.
> 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.
Ralf