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: [PATCH] (Attempt to) Fix link compatibility check (was: Re:recent mips-elf linker "architecture ... incompatible" regressions)


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


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