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

["H . J . Lu" <hjl at lucon dot org>]

On Thu, Sep 06, 2001 at 10:59:29AM -0700, cgd@broadcom.com wrote:
> "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

I won't call it silly.

> structure the question unfavforably.  I don't think I said anything
> about "an o32 binary," just a 32-bit ELF binary.
> 

I just want to make sure we are on the same page.

> 
> "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.

I think that is ok as long as R_MIPS_64 is not used for o32 binaries.
Maybe it is time to give a new BFD target for mips64-elf since it does
represent a different ABI which includes R_MIPS_64. R_MIPS_64 should be
forbidden for o32 binaries.


H.J.