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.@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,@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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
