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


Am Don, 2003-06-05 um 02.45 schrieb Svein E. Seldal:
> Hans-Peter Nilsson wrote:
> > I think I spot a misconception: the GCC target directory name
> > does *not* mandate the actual target name. 
Exactly. We currently are discussing at least 2 different issues, here:

1. Using CPU-VENDOR-OS by applications and their configure scripts. 
Here applications such as gcc and binutils can do anything they like.
If they want to treat c4x as an alias to tic4x, they'd have to implement
it.

(This is what we are trying to do for RTEMS. We currently internally use
the old string "c4x" for cpu-specific target directories and therefore
translate "tic4x" into "c4x")

2. The string returned by config.sub for a CPU-VENDOR-OS triple passed
to it. Here, once a "cpu" has been invented/introduced, there is no easy
(Actually, I think there is "no way") to deprecate/remove it, because
applications/application configure-scripts will apply them.

Imagine, Intel wants to rename "i386" into "hugo". Changing config.sub
to returning "hugo" for "i386" will break many applications, because
they apply "i386" hard-coded into it. However, this is what has happened
to "c4x".

IMO, there are only 2 ways to handle such cases in config.sub:
1. Translate the "new string" into the "old string", i.e. treat "new
string" as an alias to "old string".
2. Keep "old string" and "new string" separate and tell
users/application authors to use the "new string". Once the user base of
"old string" cpus has dried out, "old string" support in config.sub can
be removed.

> > (BTW, tic4x-elf *should* expand to tic4x-unknown-elf.  There
> > should be no need to provide a company field; if there is, it's
> > a bug.)
> 
> Yes, that is what I thought as well...
> 
> Then you please tell how to make sure that when the user enters 
> ./configure --target=tic4x, he will with the wind up with the 
> 'tic4x-unkown-coff'?
How about the patch in the attachment below?

BTW: Why does config.sub use the strings "c4x*" and "tic4x*" and not
"c4x" rsp. "tic4x" or "c4x-*" and "tic4x-*" ?

> I mean, every time I try to alter config.sub to support the tic4x-elf 
> config, it always answers 'tic4x-unknown-none'. But the BFD requires the 
> last term to be "coff", not "none". Where can I set this default?
Cf. below, AFAIS it does what all of us want it to do.

Ralf

Index: config.sub
===================================================================
RCS file: /cvsroot/config/config/config.sub,v
retrieving revision 1.280
diff -u -r1.280 config.sub
--- config.sub	2 Jun 2003 06:07:52 -0000	1.280
+++ config.sub	5 Jun 2003 04:03:30 -0000
@@ -922,9 +922,11 @@
 		basic_machine=t90-cray
 		os=-unicos
 		;;
-        tic4x | c4x*)
+        c4x*)
+		basic_machine=c4x-unknown
+		;;
+        tic4x*)
 		basic_machine=tic4x-unknown
-		os=-coff
 		;;
 	tic54x | c54x*)
 		basic_machine=tic54x-unknown
@@ -1309,6 +1311,9 @@
 		os=-elf
 		;;
 	or32-*)
+		os=-coff
+		;;
+	tic4x-*)
 		os=-coff
 		;;
 	*-tti)	# must be before sparc entry or we get the wrong os.

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