From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 25 21:27:10 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD1C08B9 for ; Wed, 25 Mar 2015 21:27:10 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 995B0616 for ; Wed, 25 Mar 2015 21:27:09 +0000 (UTC) Received: (qmail 5808 invoked from network); 25 Mar 2015 21:20:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Mar 2015 21:20:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 25 Mar 2015 17:20:29 -0400 (EDT) Received: (qmail 31358 invoked from network); 25 Mar 2015 21:20:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Mar 2015 21:20:28 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 6F8091C43AE; Wed, 25 Mar 2015 14:20:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r279514's lib/csu/powerpc64/ vs. cross builds/port builds Date: Wed, 25 Mar 2015 14:20:26 -0700 Message-Id: <52A95085-A438-4503-BCB3-0D07DDE89F9C@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:27:10 -0000 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 > lib/csu/powerpc64/crti.S:#include > lib/csu/powerpc64/crtn.S:#include 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