Re: [patch] MIPS gas problems with gcc's explicit relocs

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

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