This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] MIPS gas problems with gcc's explicit relocs
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- To: binutils at sources dot redhat dot com
- Date: Thu, 3 Jun 2004 20:28:54 +0200
- Subject: Re: [patch] MIPS gas problems with gcc's explicit relocs
- References: <Pine.LNX.4.55.0405281900120.7804@jurand.ds.pg.gda.pl> <87smdj226x.fsf@redhat.com> <Pine.LNX.4.55.0405311258240.18445@jurand.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
> Hello Richard,
>
> > I just wanted to point out that using %lo(...) in "m" constraints
> > isn't in itself a new thing. And that includes "m" constraints in
> > inline asms, since gcc doesn't treat them any differently from "m"
> > constraints in its own internal patterns. For example, if you
> > select non-abicalls o32 or o64 code, I think it's been possible
> > for "m" to use %lo(...) for some time. (Unless of course you
> > disabled it via -mno-split-addresses.)
>
> Well, it certainly is not forbidden, but it's never happened to me with
> gcc 2.95.x. I can't comment on anything between that and 3.4, though.
3.3 still leaves the argument alone.
> > If allowing %lo(...) in dla isn't acceptable (I've no opinion either
> > way really), then we'll just have to call:
> >
> > > asm("dla\t%0,%1" : "=r" (result) : "m" (foo));
> >
> > ill-formed. You should only use "m" if the instruction can handle
> > every valid memory reference.
>
> Well, I think "la" and friends should accept any valid address that is
> accepted by memory transfer instructions (it's "load address" after all --
> why should it be selective on what "address" can be?). I have no document
> providing a grammar for "la" and friends, but it's pretty well described
> in SGI's "MIPSpro Assembly Language Programmer's Guide;" for the purpose
> of references, mine is document #007-2418-004.
FWIW, I lost trust in SGI documentation some years ago.
> It lists "la" together with "lw" and other memory load instructions as
> having "destination, address" operands (table 12, page 27). So there's no
> differentiation between these two kinds of instructions. Then the format
> of "address" is specified as being one of (tables 7-8, pp 8-10):
>
> - (base-register),
>
> - expression,
>
> - expression (base-register),
>
> - index-register (base-register) (!),
>
> - relocatable-symbol,
>
> - relocatable-symbol +/- expression,
>
> - relocatable-symbol +/- expression (index register).
This list seems to mention all possible variants, but not all always
valid ones.
> There's no explicit reference to %reloc operators here and they're only
> briefly mentioned elsewhere as a possibility to refer to relocations
> explicitly (section 4.9, page 24).
AFAIK the %reloc were hacked in the SGI toolchain later, and remained
scarcely documented.
Thiemo