This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: powerpc new PLT and GOT
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~