c4x - TMS320C30-40
Joel Sherrill
joel.sherrill@OARcorp.com
Wed Jun 4 16:40:00 GMT 2003
"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'. 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.
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.
> I agree on removing the star from line 916. It shouldn't be there.
But even removing it doesn't solve everything.
> However, I do not think we can add the c4x/tic4x targets to the list
> around line 223. Because any guesses of the name 'c4x' winds up with the
> config 'c4x-unknown-none' which is incorrect, ditto for tic4x.
Fine for not adding c4x to the list of acceptable targets. But tic4x
MUST be
added. Here is my proposed patch which I think gives us both the output
we want/need:
---------------------------------------------
bash-2.05$ diff -u config.sub.orig config.sub
--- config.sub.orig Wed Jun 4 11:33:24 2003
+++ config.sub Wed Jun 4 11:38:52 2003
@@ -261,7 +261,7 @@
| sh64 | sh64le \
| sparc | sparc64 | sparc86x | sparclet | sparclite | sparcv9 |
sparcv9b \
| strongarm \
- | tahoe | thumb | tic80 | tron \
+ | tahoe | thumb | tic4x | tic80 | tron \
| v850 | v850e \
| we32k \
| x86 | xscale | xstormy16 | xtensa \
@@ -404,6 +404,9 @@
basic_machine=ns32k-sequent
os=-dynix
;;
+ c4x)
+ basic_machine=tic4x-unknown
+ ;;
c90)
basic_machine=c90-cray
os=-unicos
@@ -919,7 +922,7 @@
basic_machine=t90-cray
os=-unicos
;;
- tic4x | c4x*)
+ tic4x | c4x)
basic_machine=tic4x-unknown
os=-coff
;;
---------------------------------------------
And here is the output:
bash-2.05$ sh -x /tmp/j1
+ ./config.sub tic4x-coff
tic4x-unknown-coff
+ ./config.sub tic4x-elf
tic4x-unknown-elf
+ ./config.sub tic4x-rtems
tic4x-unknown-rtems
+ ./config.sub c4x-coff
tic4x-unknown-coff
+ ./config.sub c4x-elf
tic4x-unknown-elf
+ ./config.sub c4x-rtems
tic4x-unknown-rtems
FWIW I have modified RTEMS to use tic4x-rtems as the internal canonical
target name but for compatability would like to see c4x-rtems from a
user's perspective work also.
> The target list on line 223 selects a default company for a target
> (which is 'unknown' for the tic4x target), but it doesnt select any os
> for it (which should be 'coff' for us). This needs to be defined for the
> compilation of the binutils. Thus c4x and tic4x has its own entry in
> the list where it sets the 'tic4x-unknown-coff' triplet.
The target tic4x-rtems MUST be valid. Although the binutils may end
up being exactly the same as tic4x-coff, this is not the case for either
gcc or newlib. There are differences due to the OS.
> Given that the line 916 thing is removed, you can override this default
> behaviour by specifying a company, like this:
>
> c4x-unknown-coff
> c4x-unknown-elf
> ..etc..
>
> > How do you want to approach getting this fixed? With a bintuils release
> > and a potential gcc 3.3.1 around the corner, we have a shot at getting
> > this
> > fixed in releases.
>
> Fixes in top-level configs may take time. First you need to get an
> approval, then you need to update the top-level config in the top-level
> config repository. Then you need to convince the maintainer of gcc and
> binutils that they need to import the new toplevel config. And they may
> turn up reluctant to update top-level config's this close to releases.
But right now is a good time to get this fixed. binutils has a release
almost out the door and we can expect a gcc 3.3.1 even if no target date
has been set. I think it can be fixed and this is an ideal time. This
isn't that big a deal as long as we can get "The Right Person (tm)"
to accept the fix and propagate it to gcc, newlib, etc, etc. :)
> Regards,
> Svein
--
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
More information about the Binutils
mailing list