Re: [patch] MIPS/ELF: %call_r/%got_r operators for relocation override

[Richard Sandiford <rsandifo at redhat dot com>]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
>  Here is a patch implementing new "%call_r" and "%got_r" operators for
> explicit selection of GOT or CALL relocations.  This is for hand-coded
> assembly or old (pre-3.4) gcc implementations for which explicit
> relocation selection with "%call16", "%call_hi", "%got", etc. is
> unnecessarily tough, requiring knowledge of exact target ABI
> configuration.  OTOH, it lets gas be cleaned-up, specifically the
> imperfect heuristics for the "la" macro ($jp vs other registers) can be
> removed without sacrificing the ability for programs to use lazy binding
> via the use of CALL relocations or to defeat lazy binding where
> inappropriate via the use of GOT relocations.

Did you consider adding a new macro instead?  Maybe something like
"lca" (for "load call address")?  Reasons below.

However it's implemented, the functionality will only be available in
assemblers that also support %call16().  It seems to me like a lot of
extra code & complexity for little gain.

You say you have two users in mind:

  1. pre-3.4 gcc
  2. hand-coded assembly

Taking each in turn:

  (1) gcc's call patterns emitted fixed sequences like:

         la $25,foo
         jalr $31,$25

      with no instructions inserted inbetween.  If you're going to change
      these compilers, you might as well change them to emit "jal foo"
      instead.  There shouldn't be any performance difference.

      In fact, I suggested such a patch for gcc 3.3:

        http://gcc.gnu.org/ml/gcc-patches/2003-02/msg02235.html

      but (understandably) it was rejected as being too invasive
      for a release branch.

  (2) Hand-coded assembly.  If you want to use R_MIPS_CALL* relocs,
      there's only two possiblities: %call16() or %call_hi()/%call_lo().
      And the latter isn't needed very often now that the linker has
      multigot support.  (Again, any version of binutils that supports
      this new "la" syntax will also have multigot support.)

      If you care about performance, you're likely to be using a "normal"
      GOT and could just use %call16() directly.  If you're prepared to
      take the performance hit of using a big GOT, why not just use the
      jal macro as well?  I doubt the ability to schedule the load
      separately will have a noticeable impact.

That said, I guess (2) could be too forceful for some users and that
there might be a demand for "load address using call relocs".

As far the %reloc()-style syntax goes, I don't really see the
point of %got_r().  "la" is _supposed_ to use got relocs for PIC.
It was only a GNU-specific variation (and a well-meaning one, I know)
that caused us to use call relocs in the first place.  If we're going
to deprecate that, there should only be a need for %call_r().

And really, that's why I think a separate macro would be better.
It's much easier to parse and (IMO) is more in keeping with the
existing macros.

Richard