Re: PATCH: libffi: improvements for MIPS o32.

[Casey Marshall <csm at gnu dot org>]

>>>>> "David" == David Daney <ddaney@avtrex.com> writes:

David> Casey Marshall wrote:
>>  Hmm, defining another ABI doesn't sound like the right thing to
>> do. Are the FP/noFP ABIs similar enough to share code with o32.S?

David> We aren't defining another ABI.  It already exists, and I am
David> using it.  All I want is a way to call it via FFI.  If we want
David> to use it from FFI we need to have a FFI_MIPS_??? constant
David> defined for it.

I get it. I was thinking too much that a compiled libffi would
necessarily be tied to a single ABI type.

But now I have to ask: what is the point of having FFI_MIPS_N32 as an
ABI on O32, when there isn't any code with which you can use it?

>>  Is there a convenient check for mips32r2? Would _MIPS_ARCH check
>> this?

David> _MIPS_ARCH and friends indicate what the compiler is generating
David> code for, not where the code is currently running.  If you made
David> it depend on MIPS_ARCH then a given build of libffi could not
David> run on non mips32r2 systems unless you kept using cacheflush.
David> In which case the discussion is meaningless.  But for tightly
David> controlled environments where you knew the target CPU it would
David> work.

I thought that since you would (presumably) know which processor you
are targeting at compile-time you could configure a libffi-for-target
with -mips32r2, and let it use the instruction.

But I don't think it's worth the effort. cacheflush looks portable
enough for MIPS OSes, and if someone really needed to use synci they
could change it themselves.

-- 
Casey Marshall || csm@gnu.org