Re: powerpc new PLT and GOT

[Richard Henderson <rth@redhat.com>]

On Thu, May 12, 2005 at 06:06:50PM +0930, Alan Modra wrote:
> # ith PLT code stub.
> 	addis 11,30,(plt+(i-1)*4-got)@ha
> 	lwz 11,(plt+(i-1)*4-got)@l(11)
> 	mtctr 11
> 	bctr
> # or, if plt+(i-1)*4-got is less than 32k
> 	lwz 11,(plt+(i-1)*4-got)(30)
> 	mtctr 11
> 	bctr
> 
> # A table of branches, one for each plt entry.
> # The idea is that the plt call stub loads ctr (and r11) with these
> # addresses, so (r11 - res_0) gives the plt index * 4.
> res_0:	b PLTresolve
> res_1:	b PLTresolve
> .
> # Some number of entries towards the end can be nops
> res_n_m3: nop
> res_n_m2: nop
> res_n_m1:

I'm not thrilled, but I suppose in the normal case we'll still be
consuming only 4 words per plt.  And update forms are slow, and to
be avoided if possible.

> 	addis 11,11,(1b-res_0)@ha
> 	addi 11,11,(1b-res_0)@l
> 	sub 11,11,12			# r11 = index * 4

Reverse the res entries and you can compute

	sub 11,12,11
	subi 11,11,(1b-res_0)

> Of course, if we want to make the normal plt call path go fast, then the
> thing to do is have gcc generate the plt call stubs so that they can be
> scheduled.  So gcc generates
> 
>  addis 11,30,foo@gotplt@ha
>  lwz 11,foo@gotplt@l(11)
>  mtctr 11,foo@gotplt_marker
>  bctr foo@gotplt_marker
> 
> hopefully with other instructions scheduled in the sequence.  The funny
> looking gotplt_marker relocs are because ld might resolve "foo" to a
> local function, and would then turn the sequence into
> 
>  nop
>  nop
>  nop
>  bl foo

I don't think this is worthwhile.  IF we ever make gcc inline plt entries,
we should only do so when we have a good idea the target isn't local.
Relocations that get gotplt entries can be useful though.



r~