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

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 26 Aug 2003, Richard Sandiford wrote:

> >  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.

 I fear a couple of macros would have to be added.  But maybe only as few
as three. 

> 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.

 Hmm, the only parts that qualify as "a lot of extra code" seem to be the
parsing function and the special case of the new ABI 16-bit GOT, which
both are just a couple of lines anyway.

> 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.

 Gcc is the easy part.  It doesn't stricly emit what you quote, but:

	la $25,foo
	jalr reg,$25

permitting any register for "reg" (for whatever reason).  That's probably
why the sequence is used instead of just "jal".  But you are right that
"reg"  is effectively "$31" -- I haven't seen any pattern requesting
anything else than "ra"  and I've made a patch for gcc 2.95.4 that
restricts "reg" to "ra" and my (limited) testing haven't revealed any
failures. 

 Besides, gcc is just a single program, so it's a well-defined target to
maintain, regardless of the actual solution.

>   (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.

 The point is some code might not (or really want to) be aware of the
target ABI configuration.  And at least all three variations, i.e. 32, 64
and n32 are to be taken into consideration and then non-PIC, PIC and
PIC+xgot.  Some generic code might not have the knowledge about the target
as it's not available without user's action, but it might want to use CALL
relocations if applicable or force GOT ones where CALL ones would normally
apply.  Consider e.g. some embedded asm.

> 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".

 If we didn't support macros, I'd say: "just use the reloc operators we
already have," but we do.  And apart from simplifying assembly code they
hide most of ABI-specific addressing details.  Except that some of these
details are only available via embedded magic out of control of a
programmer, even though the magic is imperfect. 

 And perhaps expanding the operation of %call_r and %got_r to other
operations than "la"/"dla" and "jal" is going a bit too far, but it's
consistent.

> 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().

 I hope it'll get deprecated once we have an alternative, but %got_r is
still needed for "jal".  Or should we invent another macro?

> 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.

 I see a point in your suggestion -- the resulting change would be less
intrusive, indeed.  And there would be no problem whether to handle
anything beside "la"/"dla" and "jal".

 But before getting to committing actual changes I want to be sure the
solution is complete and it won't have to be rewritten as soon as some
shortcoming is discovered (or worse yet, the shortcoming will start to be
worked around in users' software).  And I prefer complex changes to
half-cooked ones. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +