From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
To: binutils@sources.redhat.com
Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas
Date: Mon, 03 Sep 2001 15:00:00 -0000
Message-id: <20010903235927.A28314@rembrandt.csv.ica.uni-stuttgart.de>
References: <20010831181657.A17249@rembrandt.csv.ica.uni-stuttgart.de> <200108311711.KAA19709@geoffk.org> <20010831193107.A10362@rembrandt.csv.ica.uni-stuttgart.de> <mailpost.999279120.2469@postal.sibyte.com> <yov51yls6sgi.fsf@highland.sibyte.com> <20010831204556.C17249@rembrandt.csv.ica.uni-stuttgart.de> <mailpost.999283589.5294@postal.sibyte.com> <yov5ofow585q.fsf@highland.sibyte.com> <20010901032235.A4969@rembrandt.csv.ica.uni-stuttgart.de> <wvn4rqk1tsj.fsf@talisman.cambridge.redhat.com>
X-SW-Source: 2001-09/msg00010.html

Richard Sandiford wrote:
> Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> > cgd@broadcom.com wrote:
> > [snip]
> > > yes, i know that the pointer is going to be constrainted to being a
> > > sign-extended 32-bit value, but neither the compiler or any assembly
> > > code that uses it needs to know that (or should).  As far as they're
> > > concerned, pointers are 64-bit values and they're loaded with ld, etc.
> > 
> > I see. Btw, my patch actually doesn't change this behaviour, the
> > HAVE_32BIT_ADDRESSES macro cares about macro expansion, so it
> > changes an address load via immediates from a "lui; daddiu" sequence
> > to "lui; addiu", this makes no difference. An "ld" isn't changed.
> 
> But HAVE_32BIT_ADDRESSES controls all the address calcuations done by
> macros, not just those that are guaranteed to be 32-bit values.  To take
> one example, if "foo" is in .sdata, won't:
> 	la $4,foo
> 
> use
> 
> 	addiu $4,$gp,foo

currently "la $4, foo" becomes with

CNU as:
   0:   3c040000        lui     a0,0x0
                        0: R_MIPS_HI16  foo
   4:   64840000        daddiu  a0,a0,0
                        4: R_MIPS_LO16  foo

GNU as with my patch:
   0:   3c040000        lui     a0,0x0
                        0: R_MIPS_HI16  foo
   4:   24840000        addiu   a0,a0,0
                        4: R_MIPS_LO16  foo

this is the same than o32 and the n32 SGI as do. It doesn't make a
difference, both are equivalent on a 64bit capable processor.
With "la" and -KPIC, there is no difference at all, but with "dla"
we have this:

GNU as with -KPIC:
   c:   df840000        ld      a0,0(gp)
                        c: R_MIPS_GOT16 foo

GNU as with my patch and -KPIC:
   c:   8f840000        lw      a0,0(gp)
                        c: R_MIPS_GOT16 foo

SGI as with -n32 -non_shared:
   0:   8f840000        lw      a0,0(gp)
                        0: R_MIPS_GOT_DISP      foo

For reference I also tried

SGI as with -64:
   0:   df840000        ld      a0,0(gp)
                        0: R_MIPS_GOT_DISP      foo

SGI as with -64 -non_shared:
   0:   3c040000        lui     a0,0x0
                        0: R_MIPS_HIGHEST       foo
   4:   64840000        daddiu  a0,a0,0
                        4: R_MIPS_HIGHER        foo
   8:   00042438        dsll    a0,a0,0x10
   c:   64840000        daddiu  a0,a0,0
                        c: R_MIPS_HI16  foo
  10:   00042438        dsll    a0,a0,0x10
  14:   64840000        daddiu  a0,a0,0
                        14: R_MIPS_LO16 foo

If somebody uses gas to address memory in 64bit space with a $gp
relative address model, this would fail with my patch (It's the
small part where I replaced "dbl" by "HAVE_32BIT_ADDRESS").
Is such a use of gas realistic?

> after your patch?  Is $gp guaranteed to be a 32-bit value when 64-bit
> pointers are being used?

In this scenario, $gp is a sign-extended 32bit value.


Thiemo