Why the "opd" section?

Why the "opd" section?

[Jonathan Bartlett]

I'm learning PPC64 assembly language, and I found the existence of the
"opd" sections containing function descriptors quite odd.  What is the use
of these?  Are they used by the linker?  Why are they needed in the 64-bit
ELF platforms and not the 32-bit ones?

Thanks,

Jon

Re: Why the "opd" section?

[Alan Modra]

On Sun, Jul 23, 2006 at 09:01:38PM -0700, Jonathan Bartlett wrote:
> I'm learning PPC64 assembly language, and I found the existence of the
> "opd" sections containing function descriptors quite odd.  What is the use
> of these?  Are they used by the linker?  Why are they needed in the 64-bit
> ELF platforms and not the 32-bit ones?

OPD is an array of function pointers.  Function pointers on powerpc64
are not just simple pointers to some code;  They specify the code entry
point, the TOC pointer, and the static chain pointer (unused by C).
To call a function, you need to know all these values because functions
do not initialise their own TOC pointer.  This allows for more efficient
code.  The compiler/linker can omit the TOC pointer load when both
caller and callee are known to share the same TOC.  (In many ways, the
TOC is like the powerpc32 GOT.  powerpc32 -fpic/PIC code initialises the
GOT pointer on entry to every function, even when caller and callee are
known to have the same GOT pointer.)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Why the "opd" section?

[Jonathan Bartlett]

> OPD is an array of function pointers.  Function pointers on powerpc64
> are not just simple pointers to some code;  They specify the code entry
> point, the TOC pointer, and the static chain pointer (unused by C).
> To call a function, you need to know all these values because functions
> do not initialise their own TOC pointer.  This allows for more efficient
> code.  The compiler/linker can omit the TOC pointer load when both
> caller and callee are known to share the same TOC.  (In many ways, the
> TOC is like the powerpc32 GOT.  powerpc32 -fpic/PIC code initialises the
> GOT pointer on entry to every function, even when caller and callee are
> known to have the same GOT pointer.)

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

Also, I tried compiling this piece of code in its own file:

int addtwo(int a)
{
        int b = addone(a);
        return addone(b);
}

I compiled it with "gcc -m64 -shared -fPIC -O3 -S tmp.c"

The resulting code had the following as it's compilation:

        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

It seems to be branching _directly_ to the opd entry, instead of the
address pointed to by the opd entry.  Also, the TOC pointer is never used,
despite the fact that these were separately compiled.  Or is this taken
care of by the linker?  Under what conditions would the TOC pointer be
different?

I'm new to PPC assembly, and a little confused.  So any help would be
appreciated.

Thanks for your time,

Jon

Re: Why the "opd" section?

[Alan Modra]

On Tue, Jul 25, 2006 at 06:23:30AM -0700, Jonathan Bartlett wrote:
> > OPD is an array of function pointers.  Function pointers on powerpc64
> > are not just simple pointers to some code;  They specify the code entry
> > point, the TOC pointer, and the static chain pointer (unused by C).
> > To call a function, you need to know all these values because functions
> > do not initialise their own TOC pointer.  This allows for more efficient
> > code.  The compiler/linker can omit the TOC pointer load when both
> > caller and callee are known to share the same TOC.  (In many ways, the
> > TOC is like the powerpc32 GOT.  powerpc32 -fpic/PIC code initialises the
> > GOT pointer on entry to every function, even when caller and callee are
> > known to have the same GOT pointer.)
> 
> 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.

> Also, I tried compiling this piece of code in its own file:
> 
> int addtwo(int a)
> {
>         int b = addone(a);
>         return addone(b);
> }
> 
> I compiled it with "gcc -m64 -shared -fPIC -O3 -S tmp.c"
> 
> The resulting code had the following as it's compilation:
> 
>         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
> 
> It seems to be branching _directly_ to the opd entry, instead of the
> address pointed to by the opd entry.  Also, the TOC pointer is never used,
> despite the fact that these were separately compiled.  Or is this taken
> care of by the linker?  Under what conditions would the TOC pointer be
> different?

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.

A number of different stubs might be used.  For a large statically
linked program where TOC size exceeds 64k, ld groups functions such that
each group uses a TOC of less than 64k, and inserts r2 adjusting stubs
between calls from one group to another.  For calls to shared library
functions, ld inserts plt call stubs that load an opd entry from the
plt.  See binutils bfd/elf64-ppc.c if you want all the gory details on
stubs.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

.tc entries question

[Jonathan Bartlett]

Another 64-bit Elf question, this one about the TOC.  In many examples,
for defining toc entries, there is some syntax like this:

name_to_refer_to_this:
.tc seemingly_unused_name[TC], data_here

I haven't figured out what the purpose of the name immediately preceding
[TC] is.  In fact, it seems that in most cases it can simply be left out.
Is this just a holdover from a previous binary format, or does
"seemingly_unused_name" actually get used in some fashion?

Thanks,

Jon

Re: .tc entries question

[Alan Modra]

On Wed, Aug 09, 2006 at 06:15:06AM -0700, Jonathan Bartlett wrote:
> Another 64-bit Elf question, this one about the TOC.  In many examples,
> for defining toc entries, there is some syntax like this:
> 
> name_to_refer_to_this:
> .tc seemingly_unused_name[TC], data_here
> 
> I haven't figured out what the purpose of the name immediately preceding
> [TC] is.  In fact, it seems that in most cases it can simply be left out.
> Is this just a holdover from a previous binary format, or does
> "seemingly_unused_name" actually get used in some fashion?

It is just a syntax we inherited from PowerPC64 XCOFF.
seemingly_unused_name and the bracketed class qualifier are completely
ingored.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre