MIPS patch to avoid lazy binding in la macros

Richard Sandiford rsandifo@redhat.com
Sun Feb 23 10:36:00 GMT 2003


Daniel Jacobowitz <drow@mvista.com> writes:
> I might be misinterpreting what you said.  I got the impression that
> your changes affected tests of undefined weak symbols equal to zero -
> was I wrong?

You're not wrong ;).  gas was (I believe) misassembling a comparison
of weak symbols against zero.  It was using an R_MIPS_CALL16 reloc
when it should have been using an R_MIPS_GOT16 reloc.  In other words,
it was allowing the weak symbol to be lazily bound, even though we
tested its address before using it.

In the example I posted, we would end up testing the stub address,
not the symbol's value.

Any gcc could emit the misassembled sequence, although I have
to admit that it's very unlikely that older ones would.

My fix was to stop the "la" macro using R_MIPS_CALL16 and go back
to using R_MIPS_GOT16.  This brings us back in line with the irix
assemblers.  Both relocs are calculated in the same way, so code
emitted by older gccs should still work.

However, as Maciej pointed out, current gcc always emits
the fixed-form string:

        la $25,foo
        jal $31,$25

instead of:

        jal foo

That's why he made gas use R_MIPS_CALL16 for "la"s like those above.

So there are two possible fixes:

1) Continue to use R_MIPS_CALL16 relocs for "la", but tighten the check.

2) Stop using R_MIPS_CALL16 relocs for "la".  If users of older gccs want
   lazy binding, they'll need to patch gcc to use "jal foo" instead.

I prefer (2) because I think that the gcc behaviour is (at best) a
misfeature.  The two-instruction sequence prevents lazy binding when
using non-GNU tools (such as when using gcc with native tools on irix).
We only got lazy binding with GNU tools because of Maciej's gas patch.

However, I'm prepared to look into (1) if you or others disagree.

Richard

PS. I never got round to committing the patch. ;)  I'll hold off
until there seems to be agreement.  Meanwhile I'll do what Eric
suggested and get patches ready for 3.2 and 3.3.



More information about the Binutils mailing list