This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas
- To: binutils at sources dot redhat dot com
- Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Date: Mon, 3 Sep 2001 23:59:27 +0200
- 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>
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