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



"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


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