[PATCH] Fix distinction of 32/64bit addresses in MIPS gas

[cgd@broadcom.com]

"H . J . Lu" <hjl@lucon.org> writes:
> > > What is the 32bit address of `foo'?
> > 
> > bit 31 may or may not be set, depending on what exactly you're
> > compiling.
> 
> Let me get this. Correct me if I am wrong. It seems that you want
> to use 64bit registers in an o32 binary. Am I right?

Uh, the way you phrase that, i get the feeling that you think i'm
silly for saying "yes."  But I think that's probably only because you
structure the question unfavforably.  I don't think I said anything
about "an o32 binary," just a 32-bit ELF binary.


"mips64-elf" tools have, historically, generated:

	* 32-bit ELF

	* mips3-compatible code (including use of full 64-bit GPRs).

Unless you say -mlong64, pointers and longs will be 32-bit, but you'll
use full 64-bit GPRs for 'long long'.

If you do say -mlong64, you'll get 64-bit pointers and longs, in your
64-bit GPRs.

All with a 32-bit ELF format.  (And, using R_MIPS_64 to represent
pointers in the object files.)

I don't really _know_ what ABI it uses.  I had always thought of it as
"o64", which in my mind was "o32 naively extended for 64-bit GPRs,"
but really i don't know that that's correct.  In fact, I don't really
_care_ what ABI it uses.  We understand the calling conventions well
enough for embedded development use, which is where we're using it.

In any case, it _does_ work (or did until recently -- i've not really
tried in the last few months with a truly vanilla mips64-elf
configuration, since we've got a clone of mips64-elf with a few minor
mods which are irrelevant for the purposes of this discussion 8-).

You can be sure that if we are, there's no shortage of others doing so
as well...




cgd