[PATCH] (Attempt to) Fix link compatibility check (was: Re: recent mips-elf linker "architecture ... incompatible" regressions)

cgd@broadcom.com cgd@broadcom.com
Tue Mar 19 18:18:00 GMT 2002


At 19 Mar 2002 18:08:24 -0800, Eric Christopher wrote:
> True, but why not just add the flag to your compile on all of your
> lines..?

mips-foo-gcc -mips64         -Dnormal -o sffp_normal.o super-fast-fp-rtns.c
mips-foo-gcc -mips64 -mips3d -Dmips3d -o sffp_mips3d.o super-fast-fp-rtns.c

?

(actually, in this one, in the final result, assuming you were
checking before calling the code, you'd want none of the ASE flags to
be set...)


> > In fact, is it really sane to produce a mips16 binary any other way?
> > (don't you typically include some mips16 code and some 'normal' mips
> > code in the same binary)?  And, shouldn't that binary be marked as
> > using the MIPS16 ASE?  8-)
> 
> Right, it should be. This would warn if you were trying to link mips16
> code in with something else, or something else with mips16 (depending on
> the order of the object files...).

Which should be?  (should be sane to produce an only-mips16 binary, or
that binary should be so marked?)

Uh, so, what you're saying is, say you compile one module w/ -mips16
and one without, and you link them together ... you get a warning?

Isn't that _exactly_ how you're supposed to use mips16?

compile your 10%-code-that-needs-high-performance with normal mips code,
compile the 90%-reset code with -mips16, link them all together, and
jalx (etc.) back and forth as needed?

i'll admit freely that i've never actually used mips16... but from
everything i've read that's how it's supposed to be used...  8-)



chris



More information about the Binutils mailing list