On Tue, Jul 25, 2006 at 11:36:34PM +0930, Alan Modra wrote:

quoted

So, why is it only in the 64-bit ELF?  Is it just because it's a newer
idea?

The idea isn't exactly new.  It's more the case that the powerpc32 ABI
is so old.

The basic idea/structure of the TOC was fixed in 1988, when the 
linkage conventions for the pre-powerpc POWER were being speced.

I have no idea why the ppc32 ABI wouldn't have used this.

quoted

        mflr 0
        std 0,16(1)
        stdu 1,-112(1)
        bl addone
        nop
        bl addone
        nop
        addi 1,1,112
        ld 0,16(1)
        mtlr 0
        blr

Yes, you're right.  It does look to be branching directly to the opd
entry at the assembly level.  It of course won't do that because
powerpc64-ld is clever enough to realise that doing so would never make
any sense.  Instead, ld does the OPD lookup and modifies the "bl" insns
to go directly to the function's code entry if the TOC vallue of caller
and callee is identical, or to go via a linker generated stub if they
are different.

I beleive the no-op provides the space for the needed extra insns when 
the linker goes to fix this up. If you disassemble the exectuable for 
the case where addone is in some shared library, you'd see the bl replaced 
by bl .glink (I think its called .glink, I don't remember), with the 
.glink code fiddling with loading the right r2 TOC pointer as needed.
I've forgotten the details.

I vaguely remember yet another interesting trick, where the linker inserts
some dynamic-link stubs -- and so, when the subroutine is called for the
very first time ever, some additional linkage is done by the stub. I
have no idea if the current gcc/glibc do this.


--linas