[patch] adjust libgloss addresses for 64-bit

[patch] adjust libgloss addresses for 64-bit

[Eric Christopher]

Here's another shot at this. The problem that we encounter is that for
64-bit addresses "la" (or dla for that matter) does not sign extend the
constant passed in the case of:

la $2,0x80000000

leaving us with a zero-extended value in a register which is
unpredictable as far as the standard (and at least one chip out there)
is concerned. One option would be to modify the assembler to
automatically sign-extend when in the presence of constants that are
smaller than a single register.

Not a bad idea, but we should also just be precise in what we pass as
well. Since gas will accept sign extended constants from la when we're
using a 64-bit pointers we can probably get by with this patch as well.
The issue of whether or not to automagically sign extend when we load
addresses is a separate one I think really in this case.

Thoughts?

-eric

2005-04-12  Eric Christopher  <echristo@redhat.com>

        * mips/regs.S: For __mips64 sign-extend K0BASE. Clean
	up K1BASE_ADDR handling.

Index: mips/regs.S
===================================================================
RCS file: /cvs/src/src/libgloss/mips/regs.S,v
retrieving revision 1.3
diff -u -p -r1.3 regs.S
--- mips/regs.S 3 Apr 2004 01:02:51 -0000       1.3
+++ mips/regs.S 14 Apr 2005 22:04:32 -0000
@@ -53,15 +53,16 @@
 #define fp1    $f1

 /* Useful memory constants: */
-#define K0BASE         0x80000000
 #ifndef __mips64
+#define K0BASE          0x80000000
 #define K1BASE         0xA0000000
 #define K0BASE_ADDR    ((char *)K0BASE)
 #define K1BASE_ADDR    ((char *)K1BASE)
 #else
-#define K1BASE         0xFFFFFFFFA0000000LL
+#define K0BASE          0xFFFFFFFF80000000
+#define K1BASE         0xFFFFFFFFA0000000
 #define K0BASE_ADDR    ((char *)0xFFFFFFFF80000000LL)
-#define K1BASE_ADDR    ((char *)K1BASE)
+#define K1BASE_ADDR    ((char *)0xFFFFFFFFA0000000LL)
 #endif

 #define PHYS_TO_K1(a)   ((unsigned)(a) | K1BASE)

Re: [patch] adjust libgloss addresses for 64-bit

[Thiemo Seufer]

Eric Christopher wrote:
> Here's another shot at this. The problem that we encounter is that for
> 64-bit addresses "la" (or dla for that matter) does not sign extend the
> constant passed in the case of:
> 
> la $2,0x80000000
> 
> leaving us with a zero-extended value in a register which is
> unpredictable as far as the standard (and at least one chip out there)
> is concerned. One option would be to modify the assembler to
> automatically sign-extend when in the presence of constants that are
> smaller than a single register.

I think la should load a proper address for 32bit address space, even
when used in code with 64bit addresses. That's the most useful
behaviour for it.

> Not a bad idea, but we should also just be precise in what we pass as
> well. Since gas will accept sign extended constants from la when we're
> using a 64-bit pointers we can probably get by with this patch as well.

FWIW, the Linux kernel uses this approach for a while now.


Thiemo

Re: [patch] adjust libgloss addresses for 64-bit

[Maciej W. Rozycki]

On Fri, 15 Apr 2005, Thiemo Seufer wrote:

> > Here's another shot at this. The problem that we encounter is that for
> > 64-bit addresses "la" (or dla for that matter) does not sign extend the
> > constant passed in the case of:
> > 
> > la $2,0x80000000
> > 
> > leaving us with a zero-extended value in a register which is
> > unpredictable as far as the standard (and at least one chip out there)

 Hmm, 0x80000000 should be a valid XKUSEG address...

> > is concerned. One option would be to modify the assembler to
> > automatically sign-extend when in the presence of constants that are
> > smaller than a single register.
> 
> I think la should load a proper address for 32bit address space, even
> when used in code with 64bit addresses. That's the most useful
> behaviour for it.

 So what should "la $2,0x80000000($3)" do when using 64-bit addresses?  
Replace/supplement the offset with a symbol as suitable...

  Maciej

Re: [patch] adjust libgloss addresses for 64-bit

[Thiemo Seufer]

Maciej W. Rozycki wrote:
[snip]
> > I think la should load a proper address for 32bit address space, even
> > when used in code with 64bit addresses. That's the most useful
> > behaviour for it.
> 
>  So what should "la $2,0x80000000($3)" do when using 64-bit addresses?  
> Replace/supplement the offset with a symbol as suitable...

Hm, looks like we break somebody's assumptions regardless what we do.
So leaving la as it is and warn about its use seems to be best.


Thiemo

Re: [patch] adjust libgloss addresses for 64-bit

[Eric Christopher]

> >  So what should "la $2,0x80000000($3)" do when using 64-bit addresses?  
> > Replace/supplement the offset with a symbol as suitable...
> 
> Hm, looks like we break somebody's assumptions regardless what we do.
> So leaving la as it is and warn about its use seems to be best.


To warn we should do two things:

1) Turn HAVE_64BIT_OBJECTS back to HAVE_64BIT_ADDRESSES in do_la.
2) Warn if we have O_constant as the type and it isn't a sign-extended
32-bit number.

-eric

Re: [patch] adjust libgloss addresses for 64-bit

[Thiemo Seufer]

Eric Christopher wrote:
> 
> > >  So what should "la $2,0x80000000($3)" do when using 64-bit addresses?  
> > > Replace/supplement the offset with a symbol as suitable...
> > 
> > Hm, looks like we break somebody's assumptions regardless what we do.
> > So leaving la as it is and warn about its use seems to be best.
> 
> 
> To warn we should do two things:
> 
> 1) Turn HAVE_64BIT_OBJECTS back to HAVE_64BIT_ADDRESSES in do_la.
> 2) Warn if we have O_constant as the type and it isn't a sign-extended
> 32-bit number.

Agreed. Maybe we can make la invalid for 64bit register after 2.16.


Thiemo

Re: [patch] adjust libgloss addresses for 64-bit

[Eric Christopher]

> > > leaving us with a zero-extended value in a register which is
> > > unpredictable as far as the standard (and at least one chip out there)
> 
>  Hmm, 0x80000000 should be a valid XKUSEG address...
> 

Nothing wrong with the address, but it's loaded as:

ori $2,0x8000
dsll $2,$2,0x10

so it's zero extended and not sign extended as it should be.

-eric

Re: [patch] adjust libgloss addresses for 64-bit

[Maciej W. Rozycki]

On Fri, 15 Apr 2005, Eric Christopher wrote:

> > > > leaving us with a zero-extended value in a register which is
> > > > unpredictable as far as the standard (and at least one chip out there)
> > 
> >  Hmm, 0x80000000 should be a valid XKUSEG address...
> > 
> 
> Nothing wrong with the address, but it's loaded as:
> 
> ori $2,0x8000
> dsll $2,$2,0x10
> 
> so it's zero extended and not sign extended as it should be.

 Of course it is zero-extended.  Otherwise it would be a different one; 
actually in the CKSEG0 space rather than XKUSEG.  If you want the former, 
what's wrong with 0xffffffff80000000? -- please keep in mind we are 
talking about 64-bit addressing.

  Maciej

Re: [patch] adjust libgloss addresses for 64-bit

[Eric Christopher]

> 
>  Of course it is zero-extended.  Otherwise it would be a different one; 
> actually in the CKSEG0 space rather than XKUSEG.  If you want the former, 
> what's wrong with 0xffffffff80000000? -- please keep in mind we are 
> talking about 64-bit addressing.

Hrm. Good point. This thread was mostly because of unpredictable errors
from the assembler in crt0.S. The "location" that crt0 is trying to load
is "K0BASE" which is likely CKSEG0, and yes, I have sign extended the
constant used in the patch that started this thread :)

(personally I think if we want to load a constant into a register using
a macro we should use li, not la).

-eric

Re: [patch] adjust libgloss addresses for 64-bit

[Maciej W. Rozycki]

On Fri, 15 Apr 2005, Eric Christopher wrote:

> (personally I think if we want to load a constant into a register using
> a macro we should use li, not la).

 Absolutely.  Sometimes it may be hard to fulfil, though, e.g. the address 
supplied may be a result of macro expansion at the preprocessing stage and 
depending on some options it may expand either to a constant or to 
something else, e.g. a symbol.  Making the instruction a part of the 
expansion may be difficult or at least obscure.  And a constant is a valid 
address after all. ;-)

  Maciej

Re: [patch] adjust libgloss addresses for 64-bit

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 15 Apr 2005, Eric Christopher wrote:
> 
> > > > > leaving us with a zero-extended value in a register which is
> > > > > unpredictable as far as the standard (and at least one chip out there)
> > > 
> > >  Hmm, 0x80000000 should be a valid XKUSEG address...
> > > 
> > 
> > Nothing wrong with the address, but it's loaded as:
> > 
> > ori $2,0x8000
> > dsll $2,$2,0x10
> > 
> > so it's zero extended and not sign extended as it should be.
> 
>  Of course it is zero-extended.  Otherwise it would be a different one; 
> actually in the CKSEG0 space rather than XKUSEG.  If you want the former, 
> what's wrong with 0xffffffff80000000? -- please keep in mind we are 
> talking about 64-bit addressing.

But people used to use "la $2, 0x80000000" in order to get a sign-extended
address. Loading two different addresses with the same code is at least
surprising. I see la in 64bit mode as backward compatibility legacy, and
this suggests not to change its behaviour.


Thiemo

Re: [patch] adjust libgloss addresses for 64-bit

[Paul Koning]

>>>>> "Thiemo" == Thiemo Seufer <ths@networkno.de> writes:

 >> Of course it is zero-extended.  Otherwise it would be a different
 >> one; actually in the CKSEG0 space rather than XKUSEG.  If you want
 >> the former, what's wrong with 0xffffffff80000000? -- please keep
 >> in mind we are talking about 64-bit addressing.

 Thiemo> But people used to use "la $2, 0x80000000" in order to get a
 Thiemo> sign-extended address. Loading two different addresses with
 Thiemo> the same code is at least surprising. I see la in 64bit mode
 Thiemo> as backward compatibility legacy, and this suggests not to
 Thiemo> change its behaviour.

Agreed.  Addresses are signed values on MIPS.  Dxx opcodes are 64 bit
operations; xx opcodes (when Dxx also exists) are 32 bit operations. 

So DLI loads a 64 bit int and LI a 32 bit int.  DLA loads a 64 bit
address and LA a 32 bit address.  So the operand of LA should be a
construct that is a valid 32 bit address (and 0x80000000 is one such)
and it should be expanded into instructions that produce a valid
representation of that address in a register (i.e., with sign
extension if the registers are 64 bits).

	  paul

Re: [patch] adjust libgloss addresses for 64-bit

[Maciej W. Rozycki]

On Fri, 15 Apr 2005, Paul Koning wrote:

> So DLI loads a 64 bit int and LI a 32 bit int.  DLA loads a 64 bit
> address and LA a 32 bit address.  So the operand of LA should be a
> construct that is a valid 32 bit address (and 0x80000000 is one such)
> and it should be expanded into instructions that produce a valid
> representation of that address in a register (i.e., with sign
> extension if the registers are 64 bits).

 With, "li" vs "dli" the definition is rather obvious and unambiguous.  
It's not with "la" vs "dla".  With the (n)64 ABI what should the 
following macros expand to:

la	$2, 0x80000000
la	$2, 0x80000000($3)
la	$2, foo + 0x80000000($3)
la	$2, foo + 0xc000000080000000($3)

In particular, assuming the RHS operand is sign-extended, should "sll $2, 
$3, 0" be performed as a part of the three latters?  What about "foo"?  
Or the 64-bit offset?

 But in principle you are right for consistency the presence or the lack 
of the "d" prefix should imply the size of the operands used as it is so 
for other assembly instructions.  So how about disabling the "wrong" 
macros completely?  That is using as_bad() for these two "dla/la used to 
load..." messages just below "do_la" that are currently warnings.  After 
all these load address macros are the only place where non-default address 
calculation rules can be argued about at all -- the interpretation of 
e.g.:

lh	$2, 0x80000000
lh	$2, 0x80000000($3)
lh	$2, foo + 0x80000000($3)
lh	$2, foo + 0xc000000080000000($3)

is rather out of question, isn't it?

  Maciej

Re: [patch] adjust libgloss addresses for 64-bit

[Paul Koning]

>>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:

 Maciej> On Fri, 15 Apr 2005, Paul Koning wrote:
 >> So DLI loads a 64 bit int and LI a 32 bit int.  DLA loads a 64 bit
 >> address and LA a 32 bit address.  So the operand of LA should be a
 >> construct that is a valid 32 bit address (and 0x80000000 is one
 >> such) and it should be expanded into instructions that produce a
 >> valid representation of that address in a register (i.e., with
 >> sign extension if the registers are 64 bits).

 Maciej> With, "li" vs "dli" the definition is rather obvious and
 Maciej> unambiguous.  It's not with "la" vs "dla".  With the (n)64
 Maciej> ABI what should the following macros expand to:

 Maciej> la $2, 0x80000000 la $2, 0x80000000($3) la $2, foo +
 Maciej> 0x80000000($3) la $2, foo + 0xc000000080000000($3)

 Maciej> In particular, assuming the RHS operand is sign-extended,
 Maciej> should "sll $2, $3, 0" be performed as a part of the three
 Maciej> latters?  What about "foo"?  Or the 64-bit offset?

In all cases, I would say the argument (offset argument in the case
where a register is also used -- didn't realize that case even
existed...) should be a 32 bit value.  So the first to cases are fine,
with sign extended values.  The third and fourth are fine if the
expression reduces to a 32 bit value.

	   paul

Re: [patch] adjust libgloss addresses for 64-bit

[Paul Koning]

>>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:

 Maciej> But in principle you are right for consistency the presence
 Maciej> or the lack of the "d" prefix should imply the size of the
 Maciej> operands used as it is so for other assembly instructions.
 Maciej> So how about disabling the "wrong" macros completely?  That
 Maciej> is using as_bad() for these two "dla/la used to load..."
 Maciej> messages just below "do_la" that are currently warnings.
 Maciej> After all these load address macros are the only place where
 Maciej> non-default address calculation rules can be argued about at
 Maciej> all -- the interpretation of e.g.:

 Maciej> lh $2, 0x80000000 lh $2, 0x80000000($3) lh $2, foo +
 Maciej> 0x80000000($3) lh $2, foo + 0xc000000080000000($3)

One answer would be to use an implicit DLA for N64, and LA otherwise.
I was thinking more about explicitly written LA vs. DLA.

All this demonstrates once again that the whole built-in macro stuff
in the MIPS assembler was a design blunder from day one.  Sigh.

Fortunately, GCC no longer uses any of this...

   paul

Re: [patch] adjust libgloss addresses for 64-bit

[Thiemo Seufer]

Paul Koning wrote:
> >>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:
> 
>  Maciej> But in principle you are right for consistency the presence
>  Maciej> or the lack of the "d" prefix should imply the size of the
>  Maciej> operands used as it is so for other assembly instructions.
>  Maciej> So how about disabling the "wrong" macros completely?  That
>  Maciej> is using as_bad() for these two "dla/la used to load..."
>  Maciej> messages just below "do_la" that are currently warnings.
>  Maciej> After all these load address macros are the only place where
>  Maciej> non-default address calculation rules can be argued about at
>  Maciej> all -- the interpretation of e.g.:
> 
>  Maciej> lh $2, 0x80000000 lh $2, 0x80000000($3) lh $2, foo +
>  Maciej> 0x80000000($3) lh $2, foo + 0xc000000080000000($3)
> 
> One answer would be to use an implicit DLA for N64, and LA otherwise.
> I was thinking more about explicitly written LA vs. DLA.
> 
> All this demonstrates once again that the whole built-in macro stuff
> in the MIPS assembler was a design blunder from day one.  Sigh.
> 
> Fortunately, GCC no longer uses any of this...

For 64bit non-PIC it still does.


Thiemo

Re: [patch] adjust libgloss addresses for 64-bit

[Richard Sandiford]

Thiemo Seufer <ths@networkno.de> writes:
>> Fortunately, GCC no longer uses any of this...
>
> For 64bit non-PIC it still does.

That's true for 3.4, but the soon-to-be-released 4.0 will avoid
macros across the board.

Richard

Re: [patch] adjust libgloss addresses for 64-bit

[cgd]

At Fri, 15 Apr 2005 19:56:48 +0100 (BST), Maciej W. Rozycki wrote:
>  With, "li" vs "dli" the definition is rather obvious and unambiguous.  
> It's not with "la" vs "dla".  With the (n)64 ABI what should the 
> following macros expand to:
> [ ... ]

Whatever SGI's assembler expands them into?  8-)

With warnings for where that differs from historic GNU binutils
behaviour?


(just a suggestion.  8-)



chris

Re: [patch] adjust libgloss addresses for 64-bit

[Maciej W. Rozycki]

On Fri, 15 Apr 2005 cgd@broadcom.com wrote:

> >  With, "li" vs "dli" the definition is rather obvious and unambiguous.  
> > It's not with "la" vs "dla".  With the (n)64 ABI what should the 
> > following macros expand to:
> > [ ... ]
> 
> Whatever SGI's assembler expands them into?  8-)

 Well, but does it actually fit all the variations of -mabi=/-march= that 
we implement?  I have no access to that tool, so I can't tell...

> With warnings for where that differs from historic GNU binutils
> behaviour?

 Well, I'd rather warn about dangerous constructs.

 Finding out the difference to historic GNU binutils behaviour may be 
tough as for the corner cases the sets will be different depending on the 
version chosen.  If you're careful enough with that choice, you may 
actually end up with disjoint sets...  Trivial cases, like "la $2, 0" are 
likely to have always worked as expected. ;-)

  Maciej

Re: [patch] adjust libgloss addresses for 64-bit

[Eric Christopher]

> > Whatever SGI's assembler expands them into?  8-)
> 
>  Well, but does it actually fit all the variations of -mabi=/-march= that 
> we implement?  I have no access to that tool, so I can't tell...
> 

No, but we can extrapolate a bit :)

>  Well, I'd rather warn about dangerous constructs.

Agreed.

-eric

Re: [patch] adjust libgloss addresses for 64-bit

[Richard Sandiford]

"Maciej W. Rozycki" <macro@linux-mips.org> writes:
>  But in principle you are right for consistency the presence or the lack 
> of the "d" prefix should imply the size of the operands used as it is so 
> for other assembly instructions.  So how about disabling the "wrong" 
> macros completely?  That is using as_bad() for these two "dla/la used to 
> load..." messages just below "do_la" that are currently warnings.  After 
> all these load address macros are the only place where non-default address 
> calculation rules can be argued about at all -- the interpretation of 
> e.g.:
>
> lh	$2, 0x80000000
> lh	$2, 0x80000000($3)
> lh	$2, foo + 0x80000000($3)
> lh	$2, foo + 0xc000000080000000($3)
>
> is rather out of question, isn't it?

Yeah, FWIW, this sounds like a good idea to me.  I think these threads
show that there's no obvious answer and that whatever we do will surprise
someone.

Richard