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:20:06 +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>
Richard Sandiford wrote:
> Hi Maciej,
>
> "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> > The recent addition of explicit relocation generation to gcc triggered
> > failures for inline assembly under certain conditions.
>
> Thanks for sticking up for the new gcc behaviour ;).
>
> 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.)
For register-indexed memory load/stores this happens to work, but
la/dla/li/dli are expanded to immediate loads. They use purely
register operations, and need the "m" reference only for its address.
> If allowing %lo(...) in dla isn't acceptable (I've no opinion either
> way really),
It's not about the %(lo) versus some constant or symbol.
I think it's a misfeature of gas to allow
la <reg>, <const>(<reg2>)
which suggests the idea of having a memory load, but expands to
lui <reg>, %hi(<const>)
addiu <reg>, %lo(<const>)
addu <reg>, <reg>
while the usual load operations like
lw <reg>, <const>(<reg2>)
expand to some actual memory access
lui <reg>, %hi(<const>)
lw <reg>, %lo(<const>)(<reg2>)
and while
li <reg>, <const>(<reg2>)
is rejected as invalid by the assembler. For gcc this problem probably
never appears, but inline assembler code should either always get the
full unprocessed argument, or we need different constraints for memory
loads and memory addresses.
Thiemo