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

[Richard Sandiford]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> - The assumption about 'la $25' being a CALL is always ok for SVR4_PIC,
>   $25 is reserved for only this purpose.

I don't think that's right.  $25's special meaning only applies at
function entry.  Other than that, it's a general temporary register
that you can use for anything.

For example, I can't see anything in the ABI that prevents you
from implementing:

        void coffee (void);
        void (*cup) (void) = coffee;
as:
        la      $25,coffee
        sw      $25,cup

Using call relocs for every load into $25 means you can't write:

        if (callback)
          callback ();

(for weak callbacks) as:

        la      $25,callback
        beqz    $25,1f
        jalr    $25
1f:

And indeed, that's what gcc was trying to do after the 3.4 rewrite.
And that's what caused me to complain earlier this year. ;)

SGI's assembler does the right thing with the $25 version, but with gas,
you have to load into a temporary:

        la      $4,callback
        beqz    $4,1f
        move    $25,$4
        jalr    $25
1f:

GCC already has a workaround for this.  But note that pre-3.4 gcc
could in theory load any function address into $25, even those that
aren't being called.  There's nothing to prevent it from emitting
the first two sequences above.

> - 'jalr lnk, trg' allows in principle other registers than $31 as link,
>   but this wouldn't conform to any ABI I know of. It could have some use
>   for highly optimized code, but such code will most likely use branches
>   instead of jumps.
> 
>   For such code, (d)lca would provide some convenience, but I don't
>   think it is actually used somewhere.

Right.  But the jalr thing was only an issue for gcc.  I think we'd
agreed that gcc only really uses $31 as the link register (and indeed,
there's no way for the user to ask for anything else).  It's just that
the call patterns were made more general than that, maybe with an eye
to some future extension that no-one ever implemented.

>From the POV of pre-3.4 gcc, "jal" should be fine.

Richard