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: Fri, 4 Jun 2004 17:10:46 +0200
- Subject: Re: [patch] MIPS gas problems with gcc's explicit relocs
- References: <Pine.LNX.4.55.0405281900120.7804@jurand.ds.pg.gda.pl> <20040528212522.GU17309@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.55.0405282326460.4045@jurand.ds.pg.gda.pl> <20040528225807.GW17309@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.55.0405290103560.4531@jurand.ds.pg.gda.pl> <20040603185053.GQ6492@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.55.0406041012060.27769@jurand.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
> On Thu, 3 Jun 2004, Thiemo Seufer wrote:
>
> > Adding some code to handle
> >
> > (d)la <reg>, %reloc(<sym>)
> >
> > isn't wrong, but probably a bit nonsensical, given that (d)la is supposed
> > to do the expansion required to handle %reloc itself (for %reloc in
> > %highest, %higher, %hi, %lo).
>
> It's the same as with other macros using addresses. E.g. "lw" is
> expected to do the same expansions, except that the last resulting
> instruction is going to be "lw" instead of "addiu"/"daddiu" (modulo
> possible instruction reordering).
My point is we have this expanion normally done either by the compiler,
or by the assembler. In the latter case, dla is supposed to get fed a
valid memory reference and do the expansion. If you want to do that
expansion manually, you can (and should, for clarity) simply use addiu
to add in the last part.
The case which led to this whole thing is IMHO a compiler bug/feature
which leads to invalid memory references fed to the dla macro.
Basically, I see three ways to handle this:
- Add a "memory address" constraint to the compiler in addition to
the "memory content" aka "m" constraint.
- Try to workaround it in the assembler. This can't be done easily,
since the 32bit relocation handling code assumes an LO16 reloc to
reference to the same address than the preceding HI16 reloc.
- Work around the problem by not using "m" constraints for (d)la in
the inline assembler, that is instead of
asm("dla\t%0,%1" : "=r" (result) : "m" (foo));
something like
asm("dla\t%0,foo" : "=r" (result));
Thiemo