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:

> > > 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. 
> 
> I have to admit I replied on the basis of the description of the patch,
> assuming %call_r() was only supposed to apply to ld/dla.  But I've just
> downloaded your test case and see you added it for a lot more:
> 
>     la  dla  jal  lb  lh  lw  ld  lbu  lhu  lwu  lwl  lwr  ll  lld
>     lwc1  ldc1  ulh  ulw  uld  sb  sh  sw  swl  sdl  swr  sdr
>     sc  scd  swc1  sdc1  ush  usw  usd

 It's not per instruction, but per address use.  So all the instructions
handled are just a result of this consistency and the test case uses them
all to make sure a possible special case doesn't creep in by accident and
break the rule.

> I can't really see a use for anything except la/dla:
> 
>     - jal
>         Why would you need to use %got_r()?  R_MIPS_CALL* will always be
>         implemented in the same way as R_MIPS_GOT* if lazy binding isn't
>         appropriate.

 Yes, if globally inappropriate. 

>         If you want to disable lazy binding for a particular call, you
>         can simply use a separate la/jalr.  I imagine that's what most
>         people would use in practice since it would work with any
>         assembler.

 I've already considered it, but I'm worrying of this case since one may
want to use "jal" to be sure the immediate R_MIPS_26 is used in the
non-PIC case.  Otherwise I'd fully agree.

>     - other loads (including ll, lld, lwc1, ldc1):
>         I don't see how R_MIPS_CALL* would be useful here.  There's no
>         way of knowing whether the load will get the first byte of the
>         target function or the first byte of a stub.
> 
>     - stores:
>         Same objection as loads.  Also, functions ought to be in a
>         non-writable segment ;)

 It's just for consistency.  I'm not particularly fond of it. ;-)

> As I understand it, the only new functionality that you're adding
> is a way to split:
> 
>         jal     foo
> 
> into something like:
> 
>         ...load address of foo into $25 using call relocs...
>         jalr    $25
> 
> presumably in an attempt to schedule the load better.  If so, I think
> at most we want "lca" and "dlca" (or whatever you want to call them).

 Yep, as I've written, that would be OK if it solved all cases.  But I'm
still uncertain of that "jal" case I've described.

> >  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).
> 
> Well, only in the sense that the return address wasn't checked by the
> define_insn.  All call insns did use $31 when they were first emitted.
> If some pass changed that later, the code would simply not work.
> 
> There's no way for the user to say "this function expects the
> incoming return address to be in $foo, not $31".

 As I've written, all callers I've tracked down use "GP_REG_FIRST + 31"
explicitly now, but if anything else was requested, emitted code would
respect it.

  Maciej

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