Why the "opd" section?

[Linas Vepstas]

On Tue, Jul 25, 2006 at 11:36:34PM +0930, Alan Modra wrote:
> > 
> > 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.

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