Date: Sun, 29 Oct 2017 06:50:08 -0700 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? Message-ID: <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> In-Reply-To: <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <CAHSQbTD8RGw6FBA0Uz2vrgOndJcvuLQZjTe_rsOSmqf9UMca=g@mail.gmail.com> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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",@progbits
stwu r1, -16(r1)
. . .
bcl 29,31,.LMAGIC_LABEL
.LMAGIC_LABEL:
mflr r30
addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha
addi r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@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",@progbits
.align 2
.globl _init
.type _init,@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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67C51163-D178-4CAC-AA3C-1178EDD22E01>