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
On Wed, 28 Jul 2010, Richard Sandiford wrote:
> > finalize_syms isn't set yet and hence resolve_symbol_value() won't make
> > the final resolution of the symbol -- see write_object_file(). We get
> > here from relax_seg() which is before finalize_syms is possibly set at the
> > earliest. Try to assemble this program:
> >
> > .text
> > .set mips16
> > foo:
> > .eqv bar, foo
> > b bar
> >
> > to trigger it.
>
> What I really meant (and I should have made it clearer) was: why can't
> we simply use the value that resolve_symbol_value gives us? It looks to
> me like it should be correct, and is more robust than an out-of-line loop.
We can, I suppose. I missed the fact resolve_symbol_value() actually
returns the value calculated. However there's one problem with that as
below...
> The problem with the patch is that it makes us go into an infinite loop for:
>
> .text
> .set mips16
> .eqv bar, foo
> .eqv foo, bar
> b bar
You're right -- I missed this case, however with your patch:
> 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'
as with no patch whatever so more investigation is required. I can't look
into it any further now, but I'll try to get back to it as soon as
possible. Thanks for your inquisitiveness.
Maciej