Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using?

Sun Oct 29 22:46:57 UTC 2017

[I add notes about what I see in the SysVR4
powerpc ABI document about r30 vs.
_GLOBAL_OFFSET_TABLE_ use --and some notes about
more modern Power Architecture® 32-bit Application
Binary Interface Supplement 1.0 material that does,
by contrast, specify a type of context where r30
must be used for the purpose. Bugzilla 206123 now
has this material as well.]

On 2017-Oct-29, at 6:50 AM, Mark Millard <markmi at dsl-only.net> wrote:

> [Message history removed as this does not flow well with
> the prior material.]
> 
> I've figured out the mismatch and, so, why/how lib32
> fails for devel/powerpc64-gcc based builds: the
> .init code generation for devel/powerpc64-gcc is tied
> to the glibc crti.S for powerpc and that does not
> match what FreeBSD has for the interface between
> the two parts.
> 
> As of 6 years ago or so glibc has code like (I'm
> only dealing with the init side of things as an
> example):
> 
> .section .init,"ax", at progbits
> stwu r1, -16(r1)
> . . .
> bcl 29,31,.LMAGIC_LABEL
> .LMAGIC_LABEL:
> mflr r30
> addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL at ha
> addi  r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL at l
> . . . (some pre-init function code) . . .
> 
> that comes before code that is from frame_dummy
> and __do_global_ctors_aux (that are from
> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c ).
> 
> The code generated for frame_dummy and
> __do_global_ctors_aux expects r30 to already
> be set up for _GLOBAL_OFFSET_TABLE_ related
> use by the kind of code that I showed above.
> 
> 
> Instead FreeBSD has for powerpc just:
> (things are configured for devel/powerpc64-gcc
> to use it)
> 
> #include <machine/asm.h>
> __FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 11:34:58Z kib $");
> 
>        .section .init,"ax", at progbits
>        .align  2
>        .globl  _init
>        .type   _init, at function
> _init:
>        stwu 1,-16(1)
>        mflr 0
>        stw 31,12(1)
>        stw 0,20(1)
>        mr 31,1
> 
> The overall result ends up being (from
> an example .so):
> 
> 0000214c <_init> stwu    r1,-16(r1)
> 00002150 <_init+0x4> mflr    r0
> 00002154 <_init+0x8> stw     r31,12(r1)
> 00002158 <_init+0xc> stw     r0,20(r1)
> 0000215c <_init+0x10> mr      r31,r1
> (The above is the FreeBSD crti.S code.)
> (Note the lack of initialization of r30
> to the _GLOBAL_OFFSET_TABLE_ related value.)
> 
> (The below is the crtstuff.c frame_dummy code
> inlined in a way that the function prolog code
> is not present here.)
> (Note the dependence on r30 having already been
> initialized.)
> 00002160 <_init+0x14> lwz     r3,-712(r30)
> 00002164 <_init+0x18> lwz     r9,0(r3)
> 00002168 <_init+0x1c> cmpwi   cr7,r9,0
> 0000216c <_init+0x20> beq-    cr7,00002184 <_init+0x38>
> 00002170 <_init+0x24> lwz     r9,-16(r30)
> 00002174 <_init+0x28> cmpwi   cr7,r9,0
> 00002178 <_init+0x2c> beq-    cr7,00002184 <_init+0x38>
> 0000217c <_init+0x30> mtctr   r9
> 00002180 <_init+0x34> bctrl
> 
> (The below is the crtstuff.c __do_global_ctors_aux
> loop code but inlined. . .)
> 00002184 <_init+0x38> lwz     r29,-36(r30)
> 00002188 <_init+0x3c> lwzu    r9,-4(r29)
> 0000218c <_init+0x40> cmpwi   cr7,r9,-1
> 00002190 <_init+0x44> beq-    cr7,000021a8 <_init+0x5c>
> 00002194 <_init+0x48> mtctr   r9
> 00002198 <_init+0x4c> bctrl
> 0000219c <_init+0x50> lwzu    r9,-4(r29)
> 000021a0 <_init+0x54> cmpwi   cr7,r9,-1
> 000021a4 <_init+0x58> bne+    cr7,00002194 <_init+0x48>
> 
> (The rest of the .init code follows.)
> 000021a8 <_init+0x5c> lwz     r11,0(r1)
> 000021ac <_init+0x60> lwz     r0,4(r11)
> 000021b0 <_init+0x64> mtlr    r0
> 000021b4 <_init+0x68> lwz     r31,-4(r11)
> 000021b8 <_init+0x6c> mr      r1,r11
> 000021bc <_init+0x70> blr
> 
> The way the compiler's source code is structured
> and works it looks to me like the crti.S used needs
> to have the initialization code for r30.

I've looked an a copy of the 1995 Sun Microsystems
PPC SYSVR4 ABI document and its table 3-3 about
processor register usage is not explicit about
a specific register being used relative to
_GLOBAL_OFFSET_TABLE_ handling.

There are examples that say things like:

Assumes GOT pointer in r31

but as far as I can tell no place requires that.
In fact there is wording like:

Combining the offset with the global offset table address in a general register (for example, r31 loaded in the sample prologue in Figure 3-33) gives the absolute address of the table entry holding the desired address.

which explicitly indicates "in a general register".

It appears that crti.S type code for share
libraries requires a local convention for
the choice of register that the compiler and
library must agree on.

So r30 looks to be a valid choice but possibly
compiler specific for a FreeBSD context.

But there may be a reason to stick with r30. . .

Looking in Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf
reports that:

Under the Secure-PLT ABI, when using the Position-Independent Code (PIC) addressing model, register r30 is used (by convention between compiler & link editor) in nonleaf functions to hold the Global Offset Table (GOT) pointer.

. . .

Using r30 to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol is the current convention used
by the compiler and link-editor and is only required for nonleaf routines which use the PIC addressing model. Leaf routines or code not using the PIC addressing model may use any available unreserved general-purpose register to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol.

. . .

The PIC call stub sequence requires that the compiler ensure that the register used to hold the _GLOBAL_OFFSET_TABLE_ pointer is set before any calls are made from the PLT. The current convention between the compiler and link editor is that r30 be used for this purpose. This is a change from the BSS-PLT ABI which only required GOT addressing to access static storage.

. . .

For non-PIC code, r30 will not hold the GOT pointer; so the stubs must be different, as shown in the following implementation.

. . .

Note: This ABI does not require a fixed GOT register, or even one register used throughout a binary. Non-PIC code does not set the _GLOBAL_OFFSET_TABLE_ pointer and does not need to reserve a register for that purpose. Code under the PIC addressing model that accesses static storage or calls nonlocal functions will need a register to hold the _GLOBAL_OFFSET_TABLE_ pointer. However, leaf functions or functions that only call other functions which are static (@local) may use any general-purpose register within the constraints for the existing ABI.

[End quotes.]

By contrast Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf
does not say much about r30 use, including not specifying
the Secure-PLT ABI material.

The referenced documents are examples of:

Power Architecture® 32-bit Application Binary Interface Supplement 1.0

documents published in, for example, 2011 (Power.org
copyright for that date but various other copyrights
for various earlier dates).

===
Mark Millard
markmi at dsl-only.net