Re: mips 64-bit address generation is broken.

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 18 Feb 2002 cgd@broadcom.com wrote:

> >  "dla" should probably be discouraged (or maybe even forbidden) for 32-bit
> > objects (see also my comments in
> > 'http://sources.redhat.com/ml/binutils/2002-02/msg00532.html' and
> > follow-ups).  And similarly for "la" and 64-bit objects.
> 
> You are incorrectly assuming that you can do that and not break a
> _large_ amount of existing code.

 I'm not assuming nothing will break.  But if anything breaks, it'll be
broken twice then. :-(

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

> 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): 

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

> But that dla doesn't expand as you expect:
> 
> > where the "dla" expands to:
> >
> > lui     $1,0x2
> > daddu   $2,$1
> 
> Because the object file is 32-bit, the assembler turns that dla into:
> 
> 	lui	$reg1, 0x2
> 	addu	$breg, $reg1
> 
> Which loses.

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

> > Using 64-bit addresses in 32-bit objects should be disallowed as they
> > don't support them -- pretending it's otherwise would at least be
> > confusing to a user and may lead to unpredictable behavior.
> 
> I'm glad you think so, but people have been using them with the GNU
> tools _for years_ and have been depending on them for embedded
> development work.

 Ok, so I'd strongly vote *for* the warning message as in my
"ulfc-mips-la" patch (or even more emphasized, like "... Effect may be
unpredictable").  Then we should drop support (if it exists at all) for
such broken configurations later, possibly after 2.13.

 There is simply no excuse for not using ELF64 these days.  Its handling
from a user's (where a user may be libelf, or whatever client code) point
of view is almost identical to ELF32, since only the address width
differs.  And you simply cannot express 64-bit addresses reliably in ELF32
(not even mentioning aesthetic issues) -- depending on exact values they
may work or not.  And if you know from elsewhere they work, then just use
32-bit addresses as you are only wasting bits anyway. 

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +