Re: mips 64-bit address generation is broken.

[cgd at broadcom dot com]

At Mon, 18 Feb 2002 21:39:26 +0100 (MET), Maciej W. Rozycki wrote:
> > There are a _lot_ of people out there using a model supported by the
> > GNU tools "forever":
> > 
> > 	* 32-bit ELF
> > 
> > 	* -mips3 or another 64-bit-GPR ISA.
> > 
> > 	* -mlong64.
> 
>  That is absolutely fine.  As I already stated this is the 32-bit mode
> (addressing mode, of course, as that's what matters to BFD) with 64-bit
> ALU.  Nothing broken here, except 64-bit addressing can't work (but isn't
> supposed to, otherwise the 64-bit mode would be chosen).

-mlong64 == 64-bit longs and pointers.

64-bit addressing had better work properly if you have 64-bit
pointers.  8-)


> > As you suggest, that compiles the example as:
> > 
> > > 2. For a 64-bit address width:
> > >
> > > ld      $2,q
> > > ld      $3,p
> > > dla     $2,131072($2)
> > > sltu    $2,$2,$3
> > 
> > (with my patch -- previously the compiler would produce 'la' which is
> > seems broken, so I tweaked the compiler...  Still working on testing
> > that patch.)
> 
>  Since you are referring to the 32-bit mode you picked the wrong option --
> the other one is relevant and it looks like a bug in the compiler but not
> where you tried to fix it.  For the 32-bit mode it should choose either: 
> 
> 1. preferably (as I have already proposed):
> 
> lw      $2,q
> lw      $3,p
> la      $2,131072($2)
> sltu    $2,$2,$3
>
> or
> 
> 2. if it can't optimize that much (but why? -- p and q are 32-bit
> variables after all): 

nope, pointers are 64-bits.  They _ARE NOT_ 32-bit variables.

> ld      $2,q
> ld      $3,p
> sllv    $2,$2,$0
> sllv    $3,$3,$0
> la      $2,131072($2)
> sltu    $2,$2,$3
> 
> none of which needs or wants a "dla".

And, use the sllv's to chop off the top bits of the addresses?

"no, thank you!  There were valid bits there."


>  Nope, at least for me.  Basically because "a 32-bit file" mean "a 32-bit
> wide address".  Plain and simple.

Alas, there are a whole bunch of people using binutils and gcc for
whom that is not true.

You cannot completely ignore their use of the tools -- they've been
using them that way for a Long Time.

Go back and read the example I provided.  Using "mips64-elf-gcc
-mlong64", that's valid code and should not abort, and currently will
be placed in a 32-bit ELF file.

Really.


>  There is simply no excuse for not using ELF64 these days.

Yes there is:

(1) does it actually _work_ right?  My personal experiences indicate
    maybe not.  Reading the to-do list in bfd/elf64-mips.c, it says
    that it doesn't support all of the stuff needed for embedded
    development use (embedded-pic).

(2) Everybody who's been doing this for years has _what_
    infrastructure built around the existing object formats?


>  As a last resort, you may always `objcopy' ELF64 statically linked final
> executables to ELF32 if some broken firmware or whatever requires it.
> Addresses in ELF file and program headers will get truncated, obviously,
> and you'll have to handle it somehow within your environment. 

Which means modifying makefiles, making sure that the result can
actually be expressed in elf32, etc.



No, from where I sit, it's really not acceptable to break the only
alternative that embedded developers have had for years...


cgd