11.0-CURRENT -r279514's lib/csu/powerpc64/ vs. cross builds/port builds

[Mark Millard]

I've been experimenting with buildworld/buildkernel based on powerpc64-xtoolchain-gcc (and with lang/gcc49) used under powerpc64 and under powerpc builds. I started from the special case of working under powerpc64 11.0-CURRENT (a self hosting cross compile for powerpc64-xtoolchain-gcc use). Then I switched to starting from powerpc (non-64) 11.0-CURRENT.

Overall this results in 3 lib/csu/powerpc64/... subject area for notes so far...


The first one is based on:

> # XXX: See the log for r232932 as to why the above -mlongcall is needed.  Since
> # clang doesn't support -mlongcall, and testing shows a clang linked with a
> # clang-built csu segfaults, this must currently be compiled with gcc.  Once
> # clang supports -mlongcall, or we get a fixed ld, this can be revisited.
> CC:=           gcc
> COMPILER_TYPE:=        gcc

This is forcing of using the path's first-found "gcc" (typically the system's 4.2.1). This overrides any XCC assignment for a cross tool chain and also overrides CC assignments for ports based that would pick out a gcc compiler instead of clang (such as lang/gcc49's 4.9.3).

I would expect that this sort of thing should be conditional on clang being in use --if cross compilers and ports-based builds are to be supported.

(I may well have wondered outside where this tier 2 environment intends to go.)

Note: 10.1-STABLE does not have the forced gcc usage in its lib/csu/powerpc64/Makefile.

Just to continue my experiment I changed the CC assignment to find the gcc that I was trying to use in order to see what else might show up.



A second subject area is: Even when the host/default gcc or other gcc is to be used it would need to be told of the target environment, both for C compiles and for assembler use. Currently this does not happen when TARGET=powerpc TARGET_ARCH=powerpc64 is used from a powerpc (non-64) host.

If from powerpc (non-64) I try to build for powerpc64 I get complaints about assembler notation associated with TOC use and notation that has @ (at sign) in use. From machine/asm.h there is the definition of the notation:

> #ifdef __powerpc64__
> #define TOC_REF(name)   __CONCAT(.L,name)
> #define TOC_ENTRY(name) \
>         .section ".toc","aw"; \
>         TOC_REF(name): \
>         .tc name[TC],name
> 
> #define _ENTRY(name) \
>         .section ".text"; \
>         .p2align 2; \
>         .globl  name; \
>         .section ".opd","aw"; \
>         .p2align 3; \
>         name: \
>         .quad   DOT_LABEL(name),.TOC. at tocbase,0; \
>         .previous; \
>         .p2align 4; \
>         TYPE_ENTRY(name) \
> DOT_LABEL(name):
> 
> #define _END(name) \
>         .long   0; \
>         .byte   0,0,0,0,0,0,0,0; \
>         END_SIZE(name)
> #else /* !__powerpc64__ */
> #define _ENTRY(name) \
>         .text; \
>         .p2align 4; \
>         .globl  name; \
>         .type   name, at function; \
>         name:
> #define _END(name)
> #endif /* __powerpc64__ */

The lack of __powerppc64__ being defined explains the parsing problems when the host is powerpc (non-64), despite TARGET_ARCH=powerpc64 use. (I've not dealt with this issue yet.)

I'll note that the TOC related parsing issue exists outside /lib/csu/... as well, such as assembling lib/libc/powerpc64/sys/brk.S . So this may not be a local lib/csu/... problem with just a local solution for using powerpc (non-64) builds to target TARGET=powerpc TARGET_ARCH=powerpc64.

From looking around it seems that this subject area might well also apply to 10.1-STABLE.



A 3rd subject area is picking files from /usr/include/sys/ and /usr/include/machine/ by default vs. from ${WORLDTMP}/usr/include/sys/ and ${WORLDTMP}/usr/include/machine/ vs. not finding various files at all. As stands the CFLAGS are assigned by:

> CFLAGS+=        -I${.CURDIR}/../common \
>                 -I${.CURDIR}/../../libc/include \
>                 -mlongcall

Looking where that suggests for libc...

> # ls lib/libc/include 
> block_abi.h	errlst.h	isc		namespace.h	nscachedcli.h	port_after.h	reentrant.h	spinlock.h
> compat.h	fpmath.h	libc_private.h	nscache.h	nss_tls.h	port_before.h	resolv_mt.h	un-namespace.h
> 


libc_private.h is used and is not in /usr/include/ or in ${WORLDTMP}/usr/include. So there is a reason to reference this area.

But there is use of (via grep):

> lib/csu/powerpc64/crt1.c:#include <sys/cdefs.h>

> lib/csu/powerpc64/crti.S:#include <machine/asm.h>
> lib/csu/powerpc64/crtn.S:#include <machine/asm.h>

which are not covered by the -I's directory trees and were not found for the cross compiler usage.

For the powerpc (non-64) host gcc it implicitly looks in /usr/include areas but cross compilers and ports compilers are not likely to look there automatically, more likely  looking someplace like /usr/local/include which has no /usr/local/include/sys/ or /usr/local/include/machine/ .

Grabbing machine/asm.h from the host machine type's /usr/include/machine/asm.h could be way wrong when the host in not a powerpc variant.

Both sys/cdefs.h and machine/asm.h could have old-vintage issues from using /usr/include/ instead of ${WORLDTMP}/usr/include/ as the basis for finding the files. (I'm not claiming likely changes.)

I used the following to get rid of those missing-include errors for a compiler/assembler that does not automatically look in /usr/include/ :

> CFLAGS+=	-I${.CURDIR}/../common \

> 		-I${WORLDTMP}/usr/include \
> 		-I${.CURDIR}/../../libc/include \
> 		-mlongcall

That used where libc_private.h is only when a file is not found in the more normal ${WORLDTMP}/usr/include/... area. Of course when the host gcc is used /usr/include/... is still potentially referenced.

I have not tried any use of --sysroot or other such to control the behavior. What I did may not have the best of behaviors.

Parts of this subject area likely applies to the 10.1-STABLE context as well form what I see looking its Makefile.



I've not dealt with the __powerpc64__-missing issues for TARGET=powerpc TARGET_ARCH=powerpc64 on powerpc (non-64) yet. That could be masking more things for me to find.

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