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]

Re: a couple of gas MIPS ABI issues.


cgd@broadcom.com wrote:
[snip]
> in the code that handles .set mipsN, in s_mipsset(), it would appear
> that if you say ".set mipsN" that can _change_ the ABI in use, and if
> you say .set mips0 that'll restore it.

Not exactly. You can switch to a different ISA, the ABI/register
size change is a side effect to make .set mipsX useful.

> I think this is erroneous for a couple of reasons:
> 
> 	* at the very least, if you're trying to restore with ".set
>           mips0", should restoration also happen if you ".set push
>           ... .set pop"?  Logically, you'd (OK, I'd 8-) think it
>           would.

That's right, I implemented this the wrong way.

> 	* I'm concerned that ".set mipsN" changes the ABI at all.  i
> 	  mean, the sizes of addresse in your GOT, etc., aren't going
> 	  to change for the binary as a whole just because you said
> 	  ".set mipsN" right?

Please understand that .set mipsX is for experienced programmers
only. It makes no guarantees about the validity of the resulting
code. It can't be replaced by a differently compiled file because
the linker might complain about it.

> 	  What's the _benefit_ of setting mips_abi = NO_ABI in the
> 	  mips3-mips5,mips64 case?  

It allows assembly beyond the ABI's restrictions.

> 	  Looks to me like that was a leftover artifact/incorrect
> 	  conversion done when getting rid of mips32_abi?

No, removing mips32_abi was spawned by getting .set mipsX right. :-)

> (It also looks to me like the setting of mips_fp32 and mips_gp32 in
> the .set mipsN code is entirely reduntant.  The code that checks those
> flags also checks the ISA reg size, since since .set mipsN also sets
> the ISA...

Why should it be redundant? .set mips3 should allow access to
64bit registers, even if the assembler was invoked with -mgp32.

> Also, there's a duplicate as_bad() there in that code;
> don't need to check default in both switches.  8-)

I like checking default, it makes the code more robust. YMMV.

> So, to go along with all that, I was also thinking, really, _should_
> changing the GPR size at run-time cause you to change the
> "HAVE_32BIT_ADDRESSES" / "HAVE_64BIT_ADDRESSES" determination?

If the addressing is determined by the ISA: Of course it should.

> I guess that the way it works now, (after fixing the NO_ABI issue
> mentioned above) ".set mipsN" will _only_ "downgrade" your address
> size (except for embedded pic 8-), except in a very strange (illegal?
> insane!) case where you're compiling for 64 bit ISA yet only with
> 32-bit GPRs.

An example where this is actually useful is the semaphore code
in Linux/MIPS. It is o32 ABI but uses a 64bit register to
do two ll ops and check the result via a scd op. This works
because there is nothing else in the system running and the
register's content isn't needed afterwards. It's a cool way
to get speedier semaphores there.

> I'm wondering if it makes sense to make the determiniation of
> HAVE_32BIT_ADDRESSES based on the command line ISA, rather than
> the current ISA potentially settable by ".set mipsN".

Right, it should be determined by the currently selected ISA.


Thiemo


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