This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: a couple of gas MIPS ABI issues.
- To: binutils at sources dot redhat dot com
- Subject: Re: a couple of gas MIPS ABI issues.
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Date: Wed, 7 Nov 2001 23:04:47 +0100
- References: <yov5d72unwr8.fsf@broadcom.com>
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