Anyone have a clue why powerpc64-gcc produces the following in /usr/lib32/crtbeginS.o ?

[Mark Millard]

Does anyone have a clue why lang/powerpc64-gcc produces the following in /usr/lib32/crtbeginS.o when WITH_LIB32= is part of what is attempted via a cross compile? Anyone that does want to enlighten me on why?

# /usr/local/powerpc64-freebsd/bin/objdump -d /usr/lib32/crtbeginS.o
. . .
Disassembly of section .init:

00000000 <.init>:
   0:	80 7e 00 00 	lwz     r3,0(r30)
   4:	81 23 00 00 	lwz     r9,0(r3)
   8:	2f 89 00 00 	cmpwi   cr7,r9,0
   c:	41 9e 00 18 	beq     cr7,24 <__do_global_dtors_aux+0x24>
  10:	81 3e 00 00 	lwz     r9,0(r30)
  14:	2f 89 00 00 	cmpwi   cr7,r9,0
  18:	41 9e 00 0c 	beq     cr7,24 <__do_global_dtors_aux+0x24>
  1c:	7d 29 03 a6 	mtctr   r9
  20:	4e 80 04 21 	bctrl

(Bug 206123)? When the code is extracted and substituted the zero offsets from R30 are replaced, such as

lwz     r3,-11432(r30)
. . .
lwz     r9,-856(r30)

for the matching pair of (R30)'s in _init in the produced /usr/lib32/libc.so.7 (position after installation).

Darwin's 32-bit ABI did reserve R30 for the frame pointer. But did anything else for some powerpc 32-bit contexts? Why would lang/powerpc64-gcc be generating Darwin-32-bit-ABI code here (if that is what the above is)?

gcc 4.2.1 instead produces:

Disassembly of section .init:

00000000 <.init>:
   0:	48 00 00 01 	bl      0 <.init>

My clang 3.8.0 based buildworld experiment for TARGET_ARCH=powerpc (non-64) got the same result as gcc 4.2.1 for this.



[Part of the reason that the clang 3.8.0 based buildworld completed is that -msoft-float support has recently been added for "ppc32", allowing libstand to not stop the build. "ppc64" does not have such yet: use of -msoft-float on the command line stops the compile with a message in clang 3.8.0 .]

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