Date: Wed, 25 Mar 2015 14:20:26 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: 11.0-CURRENT -r279514's lib/csu/powerpc64/ vs. cross builds/port builds Message-ID: <52A95085-A438-4503-BCB3-0D07DDE89F9C@dsl-only.net>
next in thread | raw e-mail | index | archive | help
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:=3D gcc
> COMPILER_TYPE:=3D 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=3Dpowerpc TARGET_ARCH=3Dpowerpc64 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. =46rom 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
>=20
> #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):
>=20
> #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=3Dpowerpc64 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=3Dpowerpc =
TARGET_ARCH=3Dpowerpc64.
=46rom 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+=3D -I${.CURDIR}/../common \
> -I${.CURDIR}/../../libc/include \
> -mlongcall
Looking where that suggests for libc...
> # ls lib/libc/include=20
> 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
>=20
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+=3D -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=3Dpowerpc =
TARGET_ARCH=3Dpowerpc64 on powerpc (non-64) yet. That could be masking =
more things for me to find.
=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?52A95085-A438-4503-BCB3-0D07DDE89F9C>