Re: c4x - TMS320C30-40

["Svein E. Seldal" <Svein dot Seldal at solidas dot com>]

I have taken the liberty to continue this discussion in the public forum 
of the binutils list...

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 agree on removing the star from line 916. It shouldn't be there.

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.

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.

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.

Regards,
Svein