This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/4] MIPS/GAS: Fix equated symbols in relaxation
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: binutils at sourceware dot org, Catherine Moore <clm at codesourcery dot com>, gnu-mips-sgxx at codesourcery dot com
- Date: Wed, 25 Aug 2010 00:33:00 +0100 (BST)
- Subject: Re: [PATCH 1/4] MIPS/GAS: Fix equated symbols in relaxation
- References: <alpine.DEB.1.10.1007241701380.29495@tp.orcam.me.uk> <87sk34py8x.fsf@firetop.home> <alpine.DEB.1.10.1007272044390.29495@tp.orcam.me.uk> <874ofjqtlw.fsf@firetop.home> <alpine.DEB.1.10.1007282136580.29495@tp.orcam.me.uk> <878w4uywf2.fsf@firetop.home>
On Thu, 29 Jul 2010, Richard Sandiford wrote:
> "Maciej W. Rozycki" <macro@codesourcery.com> writes:
> >> Index: gas/config/tc-mips.c
> >> ===================================================================
> >> RCS file: /cvs/src/src/gas/config/tc-mips.c,v
> >> retrieving revision 1.419
> >> diff -u -p -r1.419 tc-mips.c
> >> --- gas/config/tc-mips.c 28 Jun 2010 14:06:57 -0000 1.419
> >> +++ gas/config/tc-mips.c 28 Jul 2010 19:39:34 -0000
> >> @@ -14571,8 +14571,7 @@ md_convert_frag (bfd *abfd ATTRIBUTE_UNU
> >> ext = FALSE;
> >> }
> >>
> >> - resolve_symbol_value (fragp->fr_symbol);
> >> - val = S_GET_VALUE (fragp->fr_symbol);
> >> + val = resolve_symbol_value (fragp->fr_symbol);
> >> if (op->pcrel)
> >> {
> >> addressT addr;
> >
> > this program:
> >
> > .text
> > .set mips16
> > baz:
> > nop
> > .eqv bar, foo
> > .eqv foo, bar
> > b bar
> >
> > assembles to this:
> >
> > Disassembly of section .text:
> >
> > 00000000 <baz>:
> > 0: 6500 nop
> > 2: 17fe b 0 <baz>
> >
> > (no relocations) while it should yield this:
> >
> > beqv.s: Assembler messages:
> > beqv.s:7: Error: symbol definition loop encountered at `foo'
>
> Hmm, how are you testing? I get the expected error with a
> mipsisa64-elfoabi toolchain.
Fair enough -- after retesting I discovered this patch is correct and the
regression is caused by applying 2/4 on top of it -- which just means
there's yet another reason to rework 2/4 beside these you mentioned
already.
Go ahead with the change or I can do it for you if you like. And sorry
it took so long -- I keep running out of free time slots.
Maciej