Home Original page

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

Eric Christopher echristo@redhat.com
Tue Mar 19 18:27:00 GMT 2002 
> 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
> 
> ?
> 

Or how about this:

mips-foo-gcc -mips64 -mips3d foo.c
mips-foo-gcc -mips64 -mips3d bar.c

mips-foo-gcc foo.o bar.o -o a.exe

OK, so perhaps the ASEs aren't a good example at the moment, but if you
start having gcc vectorize or start using the 3d instructions when you
pass -mips3d then you start wanting it in the headers...


> 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-)

I've never seen it used this way. Most of the time I see it used where
they are going for code density all the way and just compile everything
with -mips16. For mips16 it's less of an issue (unless you start
misplacing object files and don't have mips16 support on the processor),
but I don't see the harm in warning about it either.

-eric

-- 
I will not use abbrev.
More information about the Binutils mailing list