From owner-freebsd-arm@freebsd.org Sun Jan 10 11:55:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2BEFA6B991 for ; Sun, 10 Jan 2016 11:55:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 66AA21CDA for ; Sun, 10 Jan 2016 11:55:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28799 invoked from network); 10 Jan 2016 11:55:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Jan 2016 11:55:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 10 Jan 2016 06:55:37 -0500 (EST) Received: (qmail 26680 invoked from network); 10 Jan 2016 11:55:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 10 Jan 2016 11:55:37 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 58FCD1C43AE; Sun, 10 Jan 2016 03:55:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk From: Mark Millard In-Reply-To: <1452365750.1523.9.camel@freebsd.org> Date: Sun, 10 Jan 2016 03:55:34 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <831D8A96-51D6-4E34-B422-A20857B6769E@dsl-only.net> References: <1452020032.1320.21.camel@freebsd.org> <7EE8F65E-7485-4FA9-A136-F22090DB107F@FreeBSD.org> <92264003-CF0E-4624-A28A-8AFB7C663BFB@dsl-only.net> <39774562-F76E-41E9-85E7-ABE257B013D6@FreeBSD.org> <1452365750.1523.9.camel@freebsd.org> To: Dimitry Andric , Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 11:55:42 -0000 On 2016-Jan-9, at 10:55 AM, Ian Lepore wrote: >=20 > On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >> On 09 Jan 2016, at 04:46, Mark Millard wrote: >>>=20 >>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric >>> wrote: >> ... >>>> FYI, I have added a -mno-movt option for this purpose upstream, >>>> and >>>> imported a newer snapshot into the clang380-import branch. As of >>>> r293384, it now uses the new option spelling for modules, if your >>>> clang >>>> is 3.8.0 or higher. >>>>=20 >>>> -Dimitry >>>=20 >>> I've not been able to get to the point of running clang++ 3.8 on >>> the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations >>> during the cross build's buildworld interfere. >>=20 >> Yes, this is caused by too large call distances. In other words, the >> clang executable is getting to big to link. Apparently we need to do >> some tricks with -mlongcall to fix this. As I am no arm expert, I >> welcome any patch submissions. :-) >>=20 >> -Dimitry >>=20 >=20 > Here's the patch I got from Andy for the clang380 branch, modified = with > Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE. With > this I can get a working arm world that will build a runnable > helloworld.c (and .cc) on a dreamplug. (I.e., it appears clang 3.8.0 > fixes the problem we had with clang 3.7.x where it wouldn't run at all > on armv4/5 systems). I have not tried compling anything complex yet. >=20 > -- Ian Context: When I build I normally build lldb and the like as well, even = using WITH_CLANG_EXTRAS=3D . In trying to get lldb to link I eventually get to the point that libc++ = is getting relocation truncations. Before getting to that I deal with = /usr/src/usr.bin/clang/lldb/Makefile to cover what is initially reported = during buildworld for lldb relocation truncations. Then with that in = place and retrying I get reports from libc++.a for a couple of the = contained .o files having relocations that are truncated (before it = reports "additional relocation overflows omitted from the output"): /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o) /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o) (Both have messages from multiple places in each .o file.) As far as I can tell for general use -long-calls is going to be needed = for at least some system level .a library content if the .a's are to be = used. Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for arm = system libraries fairly generally is appropriate for those intending on = building the arm-native clang toolchain and related material in = buildworld. (STATIC_CFLAGS too?) A significant case analysis of what = happens to currently be too far apart would be fragile as things grow = even more later. This sort of issue may well not be limited to TARGET=3Darm contexts. The detailed libc++.a relocation truncation complaints that I got were: > --- all_subdir_lldb --- > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hi= dden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_': > = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocat= orIS6_EEE21__push_back_slow_pathIS6_EEvOT_[_ZNSt3__16vectorINS_4pairIPNS_1= 8condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_ba= ck_slow_pathIS6_EEvOT_]+0x30): relocation truncated to fit: R_ARM_CALL = against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21= __push_back_slow_pathIRKS2_EEvOT_': > = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_= slow_pathIRKS2_EEvOT_[_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidd= en_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_]+0x30): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) . . . > --- all_subdir_clang --- > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(char const*, char = const*, char const*, char const*) const': . . . > --- all_subdir_clang --- > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x81ec): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) . . . > --- all_subdir_clang --- > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x82c0): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(char const*, char = const*) const': > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8430): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(wchar_t const*, = wchar_t const*, wchar_t const*, wchar_t const*) const': > --- all_subdir_clang --- > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x88a8): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x899c): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(wchar_t = const*, wchar_t const*) const': > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8b34): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(char const*, char = const*) const': > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIcE12do_transformEPKcS3_[_ZNKSt3__17collateIcE12do_transformEPKcS3_= ]+0x34): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(wchar_t const*, = wchar_t const*) const': > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIwE12do_transformEPKwS3_[_ZNKSt3__17collateIwE12do_transformEPKwS3_= ]+0x38): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::num_put > = >::do_put(std::__1::ostreambuf_iterator >, std::__1::ios_base&, char, long) const': > = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8= ios_baseEcl[_ZNKSt3__17num_putIcNS_19ostreambuf_iteratorIcNS_11char_traits= IcEEEEE6do_putES4_RNS_8ios_baseEcl]+0x16c): additional relocation = overflows omitted from the output Ian's/Andy's original patch is listed below for reference. > Index: lib/clang/clang.lib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/clang/clang.lib.mk (revision 293584) > +++ lib/clang/clang.lib.mk (working copy) > @@ -6,4 +6,8 @@ LLVM_SRCS=3D ${.CURDIR}/../../../contrib/llvm >=20 > INTERNALLIB=3D >=20 > +.if ${MACHINE_CPUARCH} =3D=3D "arm" > +STATIC_CXXFLAGS+=3D-mlong-calls > +.endif > + > .include > Index: lib/csu/arm/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- lib/csu/arm/Makefile (revision 293584) > +++ lib/csu/arm/Makefile (working copy) > @@ -23,7 +23,7 @@ CLEANFILES+=3D crt1.s gcrt1.s Scrt1.s > # directly compiled to .o files. >=20 > crt1.s: crt1.c > - ${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c > + ${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c > sed ${SED_FIX_NOTE} ${.TARGET} >=20 > crt1.o: crt1.s > @@ -30,7 +30,7 @@ crt1.o: crt1.s > ${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s >=20 > gcrt1.s: crt1.c > - ${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c > + ${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} = ${.CURDIR}/crt1.c > sed ${SED_FIX_NOTE} ${.TARGET} >=20 > gcrt1.o: gcrt1.s > Index: usr.bin/clang/clang/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- usr.bin/clang/clang/Makefile (revision 293584) > +++ usr.bin/clang/clang/Makefile (working copy) > @@ -11,7 +11,11 @@ SRCS=3D cc1_main.cpp \ >=20 > .if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" > NO_SHARED?=3D yes > + > +.if ${MACHINE_CPUARCH} =3D=3D "arm" > +CFLAGS+=3D-mlong-calls > .endif > +.endif >=20 > LINKS=3D ${BINDIR}/clang ${BINDIR}/clang++ \ > ${BINDIR}/clang ${BINDIR}/clang-cpp >=20 From owner-freebsd-arm@freebsd.org Sun Jan 10 12:42:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C0F0A5F28B for ; Sun, 10 Jan 2016 12:42:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7FD01423 for ; Sun, 10 Jan 2016 12:42:22 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1aIFJw-0005rA-FH for freebsd-arm@freebsd.org; Sun, 10 Jan 2016 13:42:13 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk References: <1452020032.1320.21.camel@freebsd.org> <7EE8F65E-7485-4FA9-A136-F22090DB107F@FreeBSD.org> <92264003-CF0E-4624-A28A-8AFB7C663BFB@dsl-only.net> <39774562-F76E-41E9-85E7-ABE257B013D6@FreeBSD.org> <1452365750.1523.9.camel@freebsd.org> Date: Sun, 10 Jan 2016 13:42:07 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1452365750.1523.9.camel@freebsd.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 12f61b0c8dc8dcc8c992b8e1fde77987 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 12:42:23 -0000 On Sat, 09 Jan 2016 19:55:50 +0100, Ian Lepore wrote: > On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >> On 09 Jan 2016, at 04:46, Mark Millard wrote: >> > >> > On 2016-Jan-7, at 2:57 PM, Dimitry Andric >> > wrote: >> ... >> > > FYI, I have added a -mno-movt option for this purpose upstream, >> > > and >> > > imported a newer snapshot into the clang380-import branch. As of >> > > r293384, it now uses the new option spelling for modules, if your >> > > clang >> > > is 3.8.0 or higher. >> > > >> > > -Dimitry >> > >> > I've not been able to get to the point of running clang++ 3.8 on >> > the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations >> > during the cross build's buildworld interfere. >> >> Yes, this is caused by too large call distances. In other words, the >> clang executable is getting to big to link. Apparently we need to do >> some tricks with -mlongcall to fix this. As I am no arm expert, I >> welcome any patch submissions. :-) >> >> -Dimitry >> > > Here's the patch I got from Andy for the clang380 branch, modified with > Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE. With > this I can get a working arm world that will build a runnable > helloworld.c (and .cc) on a dreamplug. (I.e., it appears clang 3.8.0 > fixes the problem we had with clang 3.7.x where it wouldn't run at all Yeah! :-) > on armv4/5 systems). I have not tried compling anything complex yet. > > -- Ian From owner-freebsd-arm@freebsd.org Sun Jan 10 17:59:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 936C2A696FF for ; Sun, 10 Jan 2016 17:59:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 5683C14D3 for ; Sun, 10 Jan 2016 17:59:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20883 invoked from network); 10 Jan 2016 17:59:34 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Jan 2016 17:59:34 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 10 Jan 2016 12:59:32 -0500 (EST) Received: (qmail 12455 invoked from network); 10 Jan 2016 17:59:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 10 Jan 2016 17:59:32 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ABCC51C43DB; Sun, 10 Jan 2016 09:59:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk From: Mark Millard In-Reply-To: <831D8A96-51D6-4E34-B422-A20857B6769E@dsl-only.net> Date: Sun, 10 Jan 2016 09:59:33 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <602C5169-40E4-4A68-9C91-214E617FC255@dsl-only.net> References: <1452020032.1320.21.camel@freebsd.org> <7EE8F65E-7485-4FA9-A136-F22090DB107F@FreeBSD.org> <92264003-CF0E-4624-A28A-8AFB7C663BFB@dsl-only.net> <39774562-F76E-41E9-85E7-ABE257B013D6@FreeBSD.org> <1452365750.1523.9.camel@freebsd.org> <831D8A96-51D6-4E34-B422-A20857B6769E@dsl-only.net> To: Dimitry Andric , Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 17:59:37 -0000 [A top post of my so far successful experiment. . .] amd64 -> rpi2 cross build: buildworld buildkernel installkernel = installworld mergemaster delete-old then boot the result on an rpi2 = worked ( -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access used ). In order to also build lldb I used the following beyond what Ian sent = out for -mlong-calls usage: (I make no claim to have tested the lldb build.) (Tabs likely not preserved in the copy/paste operations.) > # more lib_libc++_Makfile.diff=20 > Index: /usr/src/lib/libc++/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/lib/libc++/Makefile (revision 293430) > +++ /usr/src/lib/libc++/Makefile (working copy) > @@ -57,6 +57,9 @@ > .endfor > =20 > WARNS=3D 0 > +.if ${MACHINE_CPUARCH} =3D=3D "arm" > +STATIC_CXXFLAGS+=3D-mlong-calls > +.endif > CFLAGS+=3D -I${HDRDIR} -I${_LIBCXXRTDIR} -nostdlib -DLIBCXXRT > .if empty(CXXFLAGS:M-std=3D*) > CXXFLAGS+=3D -std=3Dc++11 > # more usr_bin_clang_lldb_Makefile.diff=20 > Index: /usr/src/usr.bin/clang/lldb/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/usr.bin/clang/lldb/Makefile (revision 293430) > +++ /usr/src/usr.bin/clang/lldb/Makefile (working copy) > @@ -6,6 +6,10 @@ > =20 > LLDB_SRCS=3D${.CURDIR}/../../../contrib/llvm/tools/lldb > =20 > +.if ${MACHINE_CPUARCH} =3D=3D "arm" > +CFLAGS+=3D-mlong-calls > +.endif > + > CFLAGS+=3D -I${LLDB_SRCS}/include > CXXFLAGS+=3D -std=3Dc++11 =20 The rpi2 is now attempting buildworld buildkernel targeting itself. It = is way beyond where clang 3.7.1 crashed. The above makes no claim at investigating or addressing powerpc64 = (PowerMac G5) or powerpc (PowerMac G4/G3) yet(?). So far as I know clang = mixed with the available supporting toolchain alternatives are still = insufficient for targeting those for a WITH_LIBCPLUSPLUS=3D build. = Instead something like powerpc64-xtoolchain-gcc/powerpc64-gcc must be = used, even if clang is built. (Last I knew gcc5 variations/vintages = would reject some of the WITH_CLANG_EXTRAS=3D code --but I've not tried = based on clang 3.8.0 materials.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-10, at 3:55 AM, Mark Millard wrote: >=20 >=20 > On 2016-Jan-9, at 10:55 AM, Ian Lepore wrote: >>=20 >> On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >>> On 09 Jan 2016, at 04:46, Mark Millard = wrote: >>>>=20 >>>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric >>>> wrote: >>> ... >>>>> FYI, I have added a -mno-movt option for this purpose upstream, >>>>> and >>>>> imported a newer snapshot into the clang380-import branch. As of >>>>> r293384, it now uses the new option spelling for modules, if your >>>>> clang >>>>> is 3.8.0 or higher. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> I've not been able to get to the point of running clang++ 3.8 on >>>> the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations >>>> during the cross build's buildworld interfere. >>>=20 >>> Yes, this is caused by too large call distances. In other words, = the >>> clang executable is getting to big to link. Apparently we need to = do >>> some tricks with -mlongcall to fix this. As I am no arm expert, I >>> welcome any patch submissions. :-) >>>=20 >>> -Dimitry >>>=20 >>=20 >> Here's the patch I got from Andy for the clang380 branch, modified = with >> Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE. With >> this I can get a working arm world that will build a runnable >> helloworld.c (and .cc) on a dreamplug. (I.e., it appears clang 3.8.0 >> fixes the problem we had with clang 3.7.x where it wouldn't run at = all >> on armv4/5 systems). I have not tried compling anything complex yet. >>=20 >> -- Ian >=20 >=20 > Context: When I build I normally build lldb and the like as well, even = using WITH_CLANG_EXTRAS=3D . >=20 > In trying to get lldb to link I eventually get to the point that = libc++ is getting relocation truncations. Before getting to that I deal = with /usr/src/usr.bin/clang/lldb/Makefile to cover what is initially = reported during buildworld for lldb relocation truncations. Then with = that in place and retrying I get reports from libc++.a for a couple of = the contained .o files having relocations that are truncated (before it = reports "additional relocation overflows omitted from the output"): >=20 > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o) >=20 > (Both have messages from multiple places in each .o file.) >=20 > As far as I can tell for general use -long-calls is going to be needed = for at least some system level .a library content if the .a's are to be = used. >=20 > Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for = arm system libraries fairly generally is appropriate for those intending = on building the arm-native clang toolchain and related material in = buildworld. (STATIC_CFLAGS too?) A significant case analysis of what = happens to currently be too far apart would be fragile as things grow = even more later. >=20 > This sort of issue may well not be limited to TARGET=3Darm contexts. >=20 > The detailed libc++.a relocation truncation complaints that I got = were: >=20 >=20 >> --- all_subdir_lldb --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hi= dden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocat= orIS6_EEE21__push_back_slow_pathIS6_EEvOT_[_ZNSt3__16vectorINS_4pairIPNS_1= 8condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_ba= ck_slow_pathIS6_EEvOT_]+0x30): relocation truncated to fit: R_ARM_CALL = against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21= __push_back_slow_pathIRKS2_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_= slow_pathIRKS2_EEvOT_[_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidd= en_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_]+0x30): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 > . . . >> --- all_subdir_clang --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(char const*, char = const*, char const*, char const*) const': > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x81ec): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x82c0): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8430): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(wchar_t const*, = wchar_t const*, wchar_t const*, wchar_t const*) const': >=20 >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x88a8): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x899c): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(wchar_t = const*, wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8b34): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIcE12do_transformEPKcS3_[_ZNKSt3__17collateIcE12do_transformEPKcS3_= ]+0x34): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(wchar_t const*, = wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIwE12do_transformEPKwS3_[_ZNKSt3__17collateIwE12do_transformEPKwS3_= ]+0x38): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::num_put > = >::do_put(std::__1::ostreambuf_iterator >, std::__1::ios_base&, char, long) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8= ios_baseEcl[_ZNKSt3__17num_putIcNS_19ostreambuf_iteratorIcNS_11char_traits= IcEEEEE6do_putES4_RNS_8ios_baseEcl]+0x16c): additional relocation = overflows omitted from the output >=20 >=20 > Ian's/Andy's original patch is listed below for reference. >=20 >> Index: lib/clang/clang.lib.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/clang/clang.lib.mk (revision 293584) >> +++ lib/clang/clang.lib.mk (working copy) >> @@ -6,4 +6,8 @@ LLVM_SRCS=3D ${.CURDIR}/../../../contrib/llvm >>=20 >> INTERNALLIB=3D >>=20 >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +STATIC_CXXFLAGS+=3D-mlong-calls >> +.endif >> + >> .include >> Index: lib/csu/arm/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/csu/arm/Makefile (revision 293584) >> +++ lib/csu/arm/Makefile (working copy) >> @@ -23,7 +23,7 @@ CLEANFILES+=3D crt1.s gcrt1.s Scrt1.s >> # directly compiled to .o files. >>=20 >> crt1.s: crt1.c >> - ${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> crt1.o: crt1.s >> @@ -30,7 +30,7 @@ crt1.o: crt1.s >> ${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s >>=20 >> gcrt1.s: crt1.c >> - ${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} = ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> gcrt1.o: gcrt1.s >> Index: usr.bin/clang/clang/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- usr.bin/clang/clang/Makefile (revision 293584) >> +++ usr.bin/clang/clang/Makefile (working copy) >> @@ -11,7 +11,11 @@ SRCS=3D cc1_main.cpp \ >>=20 >> .if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" >> NO_SHARED?=3D yes >> + >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +CFLAGS+=3D-mlong-calls >> .endif >> +.endif >>=20 >> LINKS=3D ${BINDIR}/clang ${BINDIR}/clang++ \ >> ${BINDIR}/clang ${BINDIR}/clang-cpp >>=20 >=20 From owner-freebsd-arm@freebsd.org Mon Jan 11 10:51:55 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77C40A6CF89 for ; Mon, 11 Jan 2016 10:51:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 3C4411DBF for ; Mon, 11 Jan 2016 10:51:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6667 invoked from network); 11 Jan 2016 10:51:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Jan 2016 10:51:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 11 Jan 2016 05:52:01 -0500 (EST) Received: (qmail 29419 invoked from network); 11 Jan 2016 10:52:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 11 Jan 2016 10:52:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 74AEE1C43C6; Mon, 11 Jan 2016 02:51:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk From: Mark Millard In-Reply-To: <602C5169-40E4-4A68-9C91-214E617FC255@dsl-only.net> Date: Mon, 11 Jan 2016 02:51:51 -0800 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <85A38C85-27C5-4998-B680-208441932563@dsl-only.net> References: <1452020032.1320.21.camel@freebsd.org> <7EE8F65E-7485-4FA9-A136-F22090DB107F@FreeBSD.org> <92264003-CF0E-4624-A28A-8AFB7C663BFB@dsl-only.net> <39774562-F76E-41E9-85E7-ABE257B013D6@FreeBSD.org> <1452365750.1523.9.camel@freebsd.org> <831D8A96-51D6-4E34-B422-A20857B6769E@dsl-only.net> <602C5169-40E4-4A68-9C91-214E617FC255@dsl-only.net> To: Dimitry Andric , Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 10:51:55 -0000 On 2016-Jan-10, at 9:59 AM, Mark Millard wrote: >=20 > [A top post of my so far successful experiment. . .] >=20 > amd64 -> rpi2 cross build: buildworld buildkernel installkernel = installworld mergemaster delete-old then boot the result on an rpi2 = worked ( -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access used ). >=20 > In order to also build lldb I used the following beyond what Ian sent = out for -mlong-calls usage: > (I make no claim to have tested the lldb build.) > (Tabs likely not preserved in the copy/paste operations.) >=20 >> # more lib_libc++_Makfile.diff=20 >> Index: /usr/src/lib/libc++/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/lib/libc++/Makefile (revision 293430) >> +++ /usr/src/lib/libc++/Makefile (working copy) >> @@ -57,6 +57,9 @@ >> .endfor >>=20 >> WARNS=3D 0 >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +STATIC_CXXFLAGS+=3D-mlong-calls >> +.endif >> CFLAGS+=3D -I${HDRDIR} -I${_LIBCXXRTDIR} -nostdlib -DLIBCXXRT >> .if empty(CXXFLAGS:M-std=3D*) >> CXXFLAGS+=3D -std=3Dc++11 >=20 >> # more usr_bin_clang_lldb_Makefile.diff=20 >> Index: /usr/src/usr.bin/clang/lldb/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/usr.bin/clang/lldb/Makefile (revision 293430) >> +++ /usr/src/usr.bin/clang/lldb/Makefile (working copy) >> @@ -6,6 +6,10 @@ >>=20 >> LLDB_SRCS=3D${.CURDIR}/../../../contrib/llvm/tools/lldb >>=20 >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +CFLAGS+=3D-mlong-calls >> +.endif >> + >> CFLAGS+=3D -I${LLDB_SRCS}/include >> CXXFLAGS+=3D -std=3Dc++11 >=20 >=20 >=20 > The rpi2 is now attempting buildworld buildkernel targeting itself. It = is way beyond where clang 3.7.1 crashed. The rpi2 finished buildworld buildkernel. To build: > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_LIB32=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D based on -target armv6--freebsd11.0-gnueabi -march=3Darmv7a = -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-access it took the = rpi2 14 hours 26 min or so. Then: installkernel; install world; shutdown -r now . . . . . . It boots and operates as hoped. For this rpi2 context clang 3.8.0 = seems to be working fine for such activity. > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r293579M: Mon Jan 11 = 07:36:21 UTC 2016 = markmi@rpi2:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm 1100093 = 1100093 > make.conf empty. src.conf (make.conf empty): > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_LIB32=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access > CXX=3D/usr/bin/clang++ -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access > CPP=3D/usr/bin/clang-cpp -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access > .export CC > .export CXX > .export CPP > .endif This vintage of src.conf presumes Ian Lepore's updates to the system's = binutils that allow them to handle armv7a movt instruction usage and the = like. RPI2-NODBG: > ident RPI2-NODBG >=20 > include "RPI2" >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols > options ALT_BREAK_TO_DEBUGGER > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC Where I've got somewhat variant source code is listed below: (This includes the recent changes to various Makefiles for arm = -mlong-call use for clang 3.8.0 .) > # svnlite status /usr/src/ > M /usr/src/contrib/libcxxrt/guard.cc > M /usr/src/lib/clang/clang.lib.mk > M /usr/src/lib/csu/arm/Makefile > M /usr/src/lib/csu/powerpc64/Makefile > M /usr/src/lib/libc++/Makefile > ? /usr/src/sys/arm/conf/RPI2-NODBG > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/uboot/Makefile.inc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/usr.bin/clang/clang/Makefile > M /usr/src/usr.bin/clang/lldb/Makefile (Most of the above is powerpc64 or powerpc specific, some even PowerMac = G5 specific.) Confirming that lldb does something: > # more main.c > int > main () > { > return 0; > } > # clang main.c > # lldb a.out > (lldb) target create "a.out" > Current executable set to 'a.out' (arm). > (lldb) run > Process 744 launching > Process 744 launched: '/root/c_tests/a.out' (arm) > Process 744 exited with status =3D 0 (0x00000000)=20 > (lldb) quit So the 2 additional Makefiles with -mlong-calls usage for arm was = sufficient. It does look like that for -march=3Darmv7a there will be an issue of = needing more use of -fpic/-fPIC and the like in ports. Otherwise things = like "unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `g_free'" = tend to occur in producing -Bsharable files. For -march=3Darmv7a -mcpu=3Dcortex-a7 there is the example of = .libs/gdkcairo.o being rejected with that message: > /bin/sh ../libtool --tag=3DCC --mode=3Dlink /usr/bin/clang -v = -target armv6--freebsd11.0-gnueabi -march=3Darmv7-a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access -pipe -mfloat-abi=3Dsoftfp = -g -fno-strict-aliasing -Wall -version-info 2400:29:2400 = -export-dynamic -rpath /usr/local/lib -export-symbols-regex "^[^_].*" = -L/usr/local/lib -o libgdk-x11-2.0.la gdk.lo gdkapplaunchcontext.lo = gdkcairo.lo gdkcolor.lo gdkcursor.lo gdkdisplay.lo gdkdisplaymanager.lo = gdkdnd.lo gdkdraw.lo gdkevents.lo gdkfont.lo gdkgc.lo gdkglobals.lo = gdkimage.lo gdkkeys.lo gdkkeyuni.lo gdkoffscreenwindow.lo gdkpango.lo = gdkpixbuf-drawable.lo gdkpixbuf-render.lo gdkpixmap.lo = gdkpolyreg-generic.lo gdkrectangle.lo gdkregion-generic.lo gdkrgb.lo = gdkscreen.lo gdkselection.lo gdkvisual.lo gdkwindow.lo gdkwindowimpl.lo = gdkenumtypes.lo gdkmarshalers.lo x11/libgdk-x11.la -L/usr/local/lib = -lpangocairo-1.0 -lpango-1.0 -lgio-2.0 -lfontconfig -lfreetype -lXrender = -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes = -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lcairo -lpthread -lX11 = -lXext -lm . . . > libtool: link: /usr/bin/clang -v -target armv6--freebsd11.0-gnueabi = -march=3Darmv7-a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access -shared .libs/gdk.o .libs/gdkapplaunchcontext.o = .libs/gdkcairo.o .libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o = .libs/gdkdisplaymanager.o .libs/gdkdnd.o .libs/gdkdraw.o = .libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o = .libs/gdkimage.o .libs/gdkkeys.o .libs/gdkkeyuni.o = .libs/gdkoffscreenwindow.o .libs/gdkpango.o .libs/gdkpixbuf-drawable.o = .libs/gdkpixbuf-render.o .libs/gdkpixmap.o .libs/gdkpolyreg-generic.o = .libs/gdkrectangle.o .libs/gdkregion-generic.o .libs/gdkrgb.o = .libs/gdkscreen.o .libs/gdkselection.o .libs/gdkvisual.o = .libs/gdkwindow.o .libs/gdkwindowimpl.o .libs/gdkenumtypes.o = .libs/gdkmarshalers.o -Wl,--whole-archive x11/.libs/libgdk-x11.a = -Wl,--no-whole-archive -L/usr/local/lib -lpangocairo-1.0 -lpango-1.0 = -lgio-2.0 -lfontconfig -lfreetype -lXrender -lXinerama -lXi -lXrandr = -lXcursor -lXcomposite -lXdamage -lXfixes -lgdk_pixbuf-2.0 -lgobject-2.0 = -lglib-2.0 -lintl -lcairo -lpthread -lX11 -lXext -lm -march=3Darmv7-a = -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-access = -mfloat-abi=3Dsoftfp -g -Wl,-soname -Wl,libgdk-x11-2.0.so.0 = -Wl,-version-script -Wl,.libs/libgdk-x11-2.0.so.0.2400.29-ver -o = .libs/libgdk-x11-2.0.so.0.2400.29 > FreeBSD clang version 3.8.0 (trunk 256945) (based on LLVM 3.8.0svn) > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > InstalledDir: /usr/bin > "/usr/bin/ld" --eh-frame-hdr -Bshareable --hash-style=3Dboth = --enable-new-dtags -o .libs/libgdk-x11-2.0.so.0.2400.29 /usr/lib/crti.o = /usr/lib/crtbeginS.o -L/usr/local/lib -L/usr/lib .libs/gdk.o = .libs/gdkapplaunchcontext.o .libs/gdkcairo.o .libs/gdkcolor.o = .libs/gdkcursor.o .libs/gdkdisplay.o .libs/gdkdisplaymanager.o = .libs/gdkdnd.o .libs/gdkdraw.o .libs/gdkevents.o .libs/gdkfont.o = .libs/gdkgc.o .libs/gdkglobals.o .libs/gdkimage.o .libs/gdkkeys.o = .libs/gdkkeyuni.o .libs/gdkoffscreenwindow.o .libs/gdkpango.o = .libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o = .libs/gdkpolyreg-generic.o .libs/gdkrectangle.o = .libs/gdkregion-generic.o .libs/gdkrgb.o .libs/gdkscreen.o = .libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o = .libs/gdkwindowimpl.o .libs/gdkenumtypes.o .libs/gdkmarshalers.o = --whole-archive x11/.libs/libgdk-x11.a --no-whole-archive = -lpangocairo-1.0 -lpango-1.0 -lgio-2.0 -lfontconfig -lfreetype -lXrender = -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes = -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lcairo -lpthread -lX11 = -lXext -lm -soname libgdk-x11-2.0.so.0 -version-script = .libs/libgdk-x11-2.0.so.0.2400.29-ver -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtendS.o /usr/lib/crtn.o > /usr/bin/ld: .libs/gdkcairo.o(.text+0x61c): unresolvable = R_ARM_MOVW_ABS_NC relocation against symbol `g_free' > /usr/bin/ld: final link failed: Nonrepresentable section on output > clang: error: linker command failed with exit code 1 (use -v to see = invocation) > Makefile:1098: recipe for target 'libgdk-x11-2.0.la' failed > gmake[6]: *** [libgdk-x11-2.0.la] Error 1 > gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' > Makefile:1238: recipe for target 'all-recursive' failed > gmake[5]: *** [all-recursive] Error 1 > gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' > Makefile:1018: recipe for target 'all' failed > gmake[4]: *** [all] Error 2 > gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' > Makefile:729: recipe for target 'all-recursive' failed > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29' > Makefile:621: recipe for target 'all' failed > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29' > =3D=3D=3D> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to > the maintainer. > *** Error code 1 Where the prior activity to produce .libs/gdkcairo.o was: > /bin/sh ../libtool --tag=3DCC --mode=3Dcompile /usr/bin/clang -v = -target armv6--freebsd11.0-gnueabi -march=3Darmv7-a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access -DHAVE_CONFIG_H -I. -I.. = -DG_LOG_DOMAIN=3D\"Gdk\" -DGDK_COMPILATION -I.. -I.. -I../gdk = -DG_DISABLE_CAST_CHECKS -I/usr/local/include/glib-2.0 = -I/usr/local/lib/glib-2.0/include -I/usr/local/include = -I/usr/local/include/pango-1.0 -I/usr/local/include/cairo = -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 = -I/usr/local/include/libdrm -I/usr/local/include/libpng16 = -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/gdk-pixbuf-2.0 = -pthread -D_THREAD_SAFE -I/usr/local/include = -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES = -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES = -I/usr/local/include -D_THREAD_SAFE -pipe -mfloat-abi=3Dsoftfp -g = -fno-strict-aliasing -Wall -MT gdkcairo.lo -MD -MP -MF = .deps/gdkcairo.Tpo -c -o gdkcairo.lo gdkcairo.c . . . > "/usr/bin/clang" -cc1 -triple armv7--freebsd11.0-gnueabi -emit-obj = -mrelax-all -disable-free -main-file-name gdkcairo.c -mrelocation-model = static -mthread-model posix -mdisable-fp-elim -relaxed-alias > ing -masm-verbose -mconstructor-aliases -target-cpu cortex-a7 = -target-feature +soft-float-abi -target-feature +strict-align = -target-abi aapcs-linux -mfloat-abi soft -v -dwarf-column-info = -debug-info-k > ind=3Dstandalone -dwarf-version=3D2 -debugger-tuning=3Dgdb = -coverage-file = /usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk/gdkc= airo.c -resource-dir /usr/bin/../lib/clang/3.8.0 -dependen > cy-file .deps/gdkcairo.Tpo -sys-header-deps -MP -MT gdkcairo.lo -D = HAVE_CONFIG_H -I . -I .. -D "G_LOG_DOMAIN=3D\"Gdk\"" -D GDK_COMPILATION = -I .. -I .. -I ../gdk -D G_DISABLE_CAST_CHECKS -I /usr/local/in > clude/glib-2.0 -I /usr/local/lib/glib-2.0/include -I = /usr/local/include -I /usr/local/include/pango-1.0 -I = /usr/local/include/cairo -I /usr/local/include/pixman-1 -I = /usr/local/include/freetype2 -I /u > sr/local/include/libdrm -I /usr/local/include/libpng16 -I = /usr/local/include/gio-unix-2.0/ -I /usr/local/include/gdk-pixbuf-2.0 -D = _THREAD_SAFE -I /usr/local/include -D G_DISABLE_SINGLE_INCLUDES -D AT > K_DISABLE_SINGLE_INCLUDES -D GDK_PIXBUF_DISABLE_SINGLE_INCLUDES -D = GTK_DISABLE_SINGLE_INCLUDES -I /usr/local/include -D _THREAD_SAFE -Wall = -fdebug-compilation-dir /usr/obj/portswork/usr/ports/x11-tool > kits/gtk20/work/gtk+-2.24.29/gdk -ferror-limit 19 -fmessage-length 200 = -pthread -fallow-half-arguments-and-returns -fno-signed-char = -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics > -o gdkcairo.o -x c gdkcairo.c . . . > libtool: compile: mv -f "gdkcairo.o" ".libs/gdkcairo.o" =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-10, at 3:55 AM, Mark Millard wrote: >=20 >=20 > On 2016-Jan-9, at 10:55 AM, Ian Lepore wrote: >>=20 >> On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >>> On 09 Jan 2016, at 04:46, Mark Millard = wrote: >>>>=20 >>>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric >>>> wrote: >>> ... >>>>> FYI, I have added a -mno-movt option for this purpose upstream, >>>>> and >>>>> imported a newer snapshot into the clang380-import branch. As of >>>>> r293384, it now uses the new option spelling for modules, if your >>>>> clang >>>>> is 3.8.0 or higher. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> I've not been able to get to the point of running clang++ 3.8 on >>>> the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations >>>> during the cross build's buildworld interfere. >>>=20 >>> Yes, this is caused by too large call distances. In other words, = the >>> clang executable is getting to big to link. Apparently we need to = do >>> some tricks with -mlongcall to fix this. As I am no arm expert, I >>> welcome any patch submissions. :-) >>>=20 >>> -Dimitry >>>=20 >>=20 >> Here's the patch I got from Andy for the clang380 branch, modified = with >> Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE. With >> this I can get a working arm world that will build a runnable >> helloworld.c (and .cc) on a dreamplug. (I.e., it appears clang 3.8.0 >> fixes the problem we had with clang 3.7.x where it wouldn't run at = all >> on armv4/5 systems). I have not tried compling anything complex yet. >>=20 >> -- Ian >=20 >=20 > Context: When I build I normally build lldb and the like as well, even = using WITH_CLANG_EXTRAS=3D . >=20 > In trying to get lldb to link I eventually get to the point that = libc++ is getting relocation truncations. Before getting to that I deal = with /usr/src/usr.bin/clang/lldb/Makefile to cover what is initially = reported during buildworld for lldb relocation truncations. Then with = that in place and retrying I get reports from libc++.a for a couple of = the contained .o files having relocations that are truncated (before it = reports "additional relocation overflows omitted from the output"): >=20 > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o) >=20 > (Both have messages from multiple places in each .o file.) >=20 > As far as I can tell for general use -long-calls is going to be needed = for at least some system level .a library content if the .a's are to be = used. >=20 > Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for = arm system libraries fairly generally is appropriate for those intending = on building the arm-native clang toolchain and related material in = buildworld. (STATIC_CFLAGS too?) A significant case analysis of what = happens to currently be too far apart would be fragile as things grow = even more later. >=20 > This sort of issue may well not be limited to TARGET=3Darm contexts. >=20 > The detailed libc++.a relocation truncation complaints that I got = were: >=20 >=20 >> --- all_subdir_lldb --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hi= dden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocat= orIS6_EEE21__push_back_slow_pathIS6_EEvOT_[_ZNSt3__16vectorINS_4pairIPNS_1= 8condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_ba= ck_slow_pathIS6_EEvOT_]+0x30): relocation truncated to fit: R_ARM_CALL = against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21= __push_back_slow_pathIRKS2_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_= slow_pathIRKS2_EEvOT_[_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidd= en_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_]+0x30): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 > . . . >> --- all_subdir_clang --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(char const*, char = const*, char const*, char const*) const': > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x81ec): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x82c0): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8430): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(wchar_t const*, = wchar_t const*, wchar_t const*, wchar_t const*) const': >=20 >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x88a8): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x899c): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(wchar_t = const*, wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8b34): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIcE12do_transformEPKcS3_[_ZNKSt3__17collateIcE12do_transformEPKcS3_= ]+0x34): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(wchar_t const*, = wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIwE12do_transformEPKwS3_[_ZNKSt3__17collateIwE12do_transformEPKwS3_= ]+0x38): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::num_put > = >::do_put(std::__1::ostreambuf_iterator >, std::__1::ios_base&, char, long) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8= ios_baseEcl[_ZNKSt3__17num_putIcNS_19ostreambuf_iteratorIcNS_11char_traits= IcEEEEE6do_putES4_RNS_8ios_baseEcl]+0x16c): additional relocation = overflows omitted from the output >=20 >=20 > Ian's/Andy's original patch is listed below for reference. >=20 >> Index: lib/clang/clang.lib.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/clang/clang.lib.mk (revision 293584) >> +++ lib/clang/clang.lib.mk (working copy) >> @@ -6,4 +6,8 @@ LLVM_SRCS=3D ${.CURDIR}/../../../contrib/llvm >>=20 >> INTERNALLIB=3D >>=20 >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +STATIC_CXXFLAGS+=3D-mlong-calls >> +.endif >> + >> .include >> Index: lib/csu/arm/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/csu/arm/Makefile (revision 293584) >> +++ lib/csu/arm/Makefile (working copy) >> @@ -23,7 +23,7 @@ CLEANFILES+=3D crt1.s gcrt1.s Scrt1.s >> # directly compiled to .o files. >>=20 >> crt1.s: crt1.c >> - ${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> crt1.o: crt1.s >> @@ -30,7 +30,7 @@ crt1.o: crt1.s >> ${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s >>=20 >> gcrt1.s: crt1.c >> - ${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} = ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> gcrt1.o: gcrt1.s >> Index: usr.bin/clang/clang/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- usr.bin/clang/clang/Makefile (revision 293584) >> +++ usr.bin/clang/clang/Makefile (working copy) >> @@ -11,7 +11,11 @@ SRCS=3D cc1_main.cpp \ >>=20 >> .if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" >> NO_SHARED?=3D yes >> + >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +CFLAGS+=3D-mlong-calls >> .endif >> +.endif >>=20 >> LINKS=3D ${BINDIR}/clang ${BINDIR}/clang++ \ >> ${BINDIR}/clang ${BINDIR}/clang-cpp >>=20 >=20 From owner-freebsd-arm@freebsd.org Mon Jan 11 12:56:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8C36A692AD for ; Mon, 11 Jan 2016 12:56:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-3.reflexion.net [208.70.210.3]) (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 748201EC6 for ; Mon, 11 Jan 2016 12:56:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23369 invoked from network); 11 Jan 2016 12:56:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Jan 2016 12:56:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 11 Jan 2016 07:56:09 -0500 (EST) Received: (qmail 21846 invoked from network); 11 Jan 2016 12:56:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 11 Jan 2016 12:56:09 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 233011C43C6; Mon, 11 Jan 2016 04:55:59 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk From: Mark Millard In-Reply-To: <85A38C85-27C5-4998-B680-208441932563@dsl-only.net> Date: Mon, 11 Jan 2016 04:56:00 -0800 Cc: freebsd-arm , FreeBSD Toolchain Message-Id: References: <1452020032.1320.21.camel@freebsd.org> <7EE8F65E-7485-4FA9-A136-F22090DB107F@FreeBSD.org> <92264003-CF0E-4624-A28A-8AFB7C663BFB@dsl-only.net> <39774562-F76E-41E9-85E7-ABE257B013D6@FreeBSD.org> <1452365750.1523.9.camel@freebsd.org> <831D8A96-51D6-4E34-B422-A20857B6769E@dsl-only.net> <602C5169-40E4-4A68-9C91-214E617FC255@dsl-only.net> <85A38C85-27C5-4998-B680-208441932563@dsl-only.net> To: Dimitry Andric , Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 12:56:08 -0000 Quick top post of a correction to a mistake of mine about the ports = issue: The notes about -fpic/-fPIC issues with ports are wrong and the issue = was self inflicted: using -v on the clang or clang++ command lines = messes up autoconf/libtool by them not handling the extra output text = well. Many ports depend on those tools. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-11, at 2:51 AM, Mark Millard wrote: >=20 >=20 > On 2016-Jan-10, at 9:59 AM, Mark Millard = wrote: >>=20 >> [A top post of my so far successful experiment. . .] >>=20 >> amd64 -> rpi2 cross build: buildworld buildkernel installkernel = installworld mergemaster delete-old then boot the result on an rpi2 = worked ( -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access used ). >>=20 >> In order to also build lldb I used the following beyond what Ian sent = out for -mlong-calls usage: >> (I make no claim to have tested the lldb build.) >> (Tabs likely not preserved in the copy/paste operations.) >>=20 >>> # more lib_libc++_Makfile.diff=20 >>> Index: /usr/src/lib/libc++/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /usr/src/lib/libc++/Makefile (revision 293430) >>> +++ /usr/src/lib/libc++/Makefile (working copy) >>> @@ -57,6 +57,9 @@ >>> .endfor >>>=20 >>> WARNS=3D 0 >>> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >>> +STATIC_CXXFLAGS+=3D-mlong-calls >>> +.endif >>> CFLAGS+=3D -I${HDRDIR} -I${_LIBCXXRTDIR} -nostdlib -DLIBCXXRT >>> .if empty(CXXFLAGS:M-std=3D*) >>> CXXFLAGS+=3D -std=3Dc++11 >>=20 >>> # more usr_bin_clang_lldb_Makefile.diff=20 >>> Index: /usr/src/usr.bin/clang/lldb/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- /usr/src/usr.bin/clang/lldb/Makefile (revision 293430) >>> +++ /usr/src/usr.bin/clang/lldb/Makefile (working copy) >>> @@ -6,6 +6,10 @@ >>>=20 >>> LLDB_SRCS=3D${.CURDIR}/../../../contrib/llvm/tools/lldb >>>=20 >>> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >>> +CFLAGS+=3D-mlong-calls >>> +.endif >>> + >>> CFLAGS+=3D -I${LLDB_SRCS}/include >>> CXXFLAGS+=3D -std=3Dc++11 >>=20 >>=20 >>=20 >> The rpi2 is now attempting buildworld buildkernel targeting itself. = It is way beyond where clang 3.7.1 crashed. >=20 >=20 >=20 > The rpi2 finished buildworld buildkernel. To build: >=20 >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >> WITH_CLANG_EXTRAS=3D >> WITH_BOOT=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_CLANG_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_LIB32=3D >> WITHOUT_GCC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D >=20 > based on -target armv6--freebsd11.0-gnueabi -march=3Darmv7a = -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-access it took the = rpi2 14 hours 26 min or so. >=20 > Then: installkernel; install world; shutdown -r now . . . >=20 > . . . It boots and operates as hoped. For this rpi2 context clang = 3.8.0 seems to be working fine for such activity. >=20 >> # freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r293579M: Mon Jan = 11 07:36:21 UTC 2016 = markmi@rpi2:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm 1100093 = 1100093 >> make.conf empty. >=20 > src.conf (make.conf empty): >=20 >> TO_TYPE=3Darmv6 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >> WITH_CLANG_EXTRAS=3D >> WITH_BOOT=3D >> # >> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITHOUT_CLANG_BOOTSTRAP=3D >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_LIB32=3D >> WITHOUT_GCC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> XCC=3D/usr/bin/clang -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access >> .export XCC >> .export XCXX >> .export XCPP >> .endif >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> CC=3D/usr/bin/clang -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access >> CXX=3D/usr/bin/clang++ -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access >> CPP=3D/usr/bin/clang-cpp -v -march=3Darmv7a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access >> .export CC >> .export CXX >> .export CPP >> .endif >=20 > This vintage of src.conf presumes Ian Lepore's updates to the system's = binutils that allow them to handle armv7a movt instruction usage and the = like. >=20 >=20 > RPI2-NODBG: >=20 >> ident RPI2-NODBG >>=20 >> include "RPI2" >>=20 >> makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >> options ALT_BREAK_TO_DEBUGGER >> #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >>=20 >> options KDB # Enable kernel debugger = support >>=20 >> # For minimum debugger support (stable branch) use: >> #options KDB_TRACE # Print a stack trace for a = panic >> options DDB # Enable the kernel debugger >>=20 >> nooptions INVARIANTS # Enable calls of extra = sanity checking >> nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS >> nooptions WITNESS # Enable checks to detect = deadlocks and cycles >> nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed >> nooptions DIAGNOSTIC >=20 >=20 > Where I've got somewhat variant source code is listed below: > (This includes the recent changes to various Makefiles for arm = -mlong-call use for clang 3.8.0 .) >=20 >> # svnlite status /usr/src/ >> M /usr/src/contrib/libcxxrt/guard.cc >> M /usr/src/lib/clang/clang.lib.mk >> M /usr/src/lib/csu/arm/Makefile >> M /usr/src/lib/csu/powerpc64/Makefile >> M /usr/src/lib/libc++/Makefile >> ? /usr/src/sys/arm/conf/RPI2-NODBG >> M /usr/src/sys/boot/ofw/Makefile.inc >> M /usr/src/sys/boot/powerpc/Makefile.inc >> M /usr/src/sys/boot/uboot/Makefile.inc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc >> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG >> ? /usr/src/sys/powerpc/conf/GENERICvtsc >> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG >> M /usr/src/sys/powerpc/ofw/ofw_machdep.c >> M /usr/src/usr.bin/clang/clang/Makefile >> M /usr/src/usr.bin/clang/lldb/Makefile >=20 > (Most of the above is powerpc64 or powerpc specific, some even = PowerMac G5 specific.) >=20 >=20 > Confirming that lldb does something: >=20 >> # more main.c >> int >> main () >> { >> return 0; >> } >> # clang main.c >> # lldb a.out >> (lldb) target create "a.out" >> Current executable set to 'a.out' (arm). >> (lldb) run >> Process 744 launching >> Process 744 launched: '/root/c_tests/a.out' (arm) >> Process 744 exited with status =3D 0 (0x00000000)=20 >> (lldb) quit >=20 > So the 2 additional Makefiles with -mlong-calls usage for arm was = sufficient. >=20 >=20 >=20 > It does look like that for -march=3Darmv7a there will be an issue of = needing more use of -fpic/-fPIC and the like in ports. Otherwise things = like "unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `g_free'" = tend to occur in producing -Bsharable files. >=20 > For -march=3Darmv7a -mcpu=3Dcortex-a7 there is the example of = .libs/gdkcairo.o being rejected with that message: >=20 >> /bin/sh ../libtool --tag=3DCC --mode=3Dlink /usr/bin/clang -v = -target armv6--freebsd11.0-gnueabi -march=3Darmv7-a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access -pipe -mfloat-abi=3Dsoftfp = -g -fno-strict-aliasing -Wall -version-info 2400:29:2400 = -export-dynamic -rpath /usr/local/lib -export-symbols-regex "^[^_].*" = -L/usr/local/lib -o libgdk-x11-2.0.la gdk.lo gdkapplaunchcontext.lo = gdkcairo.lo gdkcolor.lo gdkcursor.lo gdkdisplay.lo gdkdisplaymanager.lo = gdkdnd.lo gdkdraw.lo gdkevents.lo gdkfont.lo gdkgc.lo gdkglobals.lo = gdkimage.lo gdkkeys.lo gdkkeyuni.lo gdkoffscreenwindow.lo gdkpango.lo = gdkpixbuf-drawable.lo gdkpixbuf-render.lo gdkpixmap.lo = gdkpolyreg-generic.lo gdkrectangle.lo gdkregion-generic.lo gdkrgb.lo = gdkscreen.lo gdkselection.lo gdkvisual.lo gdkwindow.lo gdkwindowimpl.lo = gdkenumtypes.lo gdkmarshalers.lo x11/libgdk-x11.la -L/usr/local/lib = -lpangocairo-1.0 -lpango-1.0 -lgio-2.0 -lfontconfig -lfreetype -lXrender = -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes = -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lcairo -lpthread -lX11 = -lXext -lm > . . . >> libtool: link: /usr/bin/clang -v -target armv6--freebsd11.0-gnueabi = -march=3Darmv7-a -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp = -mno-unaligned-access -shared .libs/gdk.o .libs/gdkapplaunchcontext.o = .libs/gdkcairo.o .libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o = .libs/gdkdisplaymanager.o .libs/gdkdnd.o .libs/gdkdraw.o = .libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o = .libs/gdkimage.o .libs/gdkkeys.o .libs/gdkkeyuni.o = .libs/gdkoffscreenwindow.o .libs/gdkpango.o .libs/gdkpixbuf-drawable.o = .libs/gdkpixbuf-render.o .libs/gdkpixmap.o .libs/gdkpolyreg-generic.o = .libs/gdkrectangle.o .libs/gdkregion-generic.o .libs/gdkrgb.o = .libs/gdkscreen.o .libs/gdkselection.o .libs/gdkvisual.o = .libs/gdkwindow.o .libs/gdkwindowimpl.o .libs/gdkenumtypes.o = .libs/gdkmarshalers.o -Wl,--whole-archive x11/.libs/libgdk-x11.a = -Wl,--no-whole-archive -L/usr/local/lib -lpangocairo-1.0 -lpango-1.0 = -lgio-2.0 -lfontconfig -lfreetype -lXrender -lXinerama -lXi -lXrandr = -lXcursor -lXcomposite -lXdamage -lXfixes -lgdk_pixbuf-2.0 -lgobject-2.0 = -lglib-2.0 -lintl -lcairo -lpthread -lX11 -lXext -lm -march=3Darmv7-a = -mcpu=3Dcortex-a7 -mfloat-abi=3Dsoftfp -mno-unaligned-access = -mfloat-abi=3Dsoftfp -g -Wl,-soname -Wl,libgdk-x11-2.0.so.0 = -Wl,-version-script -Wl,.libs/libgdk-x11-2.0.so.0.2400.29-ver -o = .libs/libgdk-x11-2.0.so.0.2400.29 >> FreeBSD clang version 3.8.0 (trunk 256945) (based on LLVM 3.8.0svn) >> Target: armv6--freebsd11.0-gnueabi >> Thread model: posix >> InstalledDir: /usr/bin >> "/usr/bin/ld" --eh-frame-hdr -Bshareable --hash-style=3Dboth = --enable-new-dtags -o .libs/libgdk-x11-2.0.so.0.2400.29 /usr/lib/crti.o = /usr/lib/crtbeginS.o -L/usr/local/lib -L/usr/lib .libs/gdk.o = .libs/gdkapplaunchcontext.o .libs/gdkcairo.o .libs/gdkcolor.o = .libs/gdkcursor.o .libs/gdkdisplay.o .libs/gdkdisplaymanager.o = .libs/gdkdnd.o .libs/gdkdraw.o .libs/gdkevents.o .libs/gdkfont.o = .libs/gdkgc.o .libs/gdkglobals.o .libs/gdkimage.o .libs/gdkkeys.o = .libs/gdkkeyuni.o .libs/gdkoffscreenwindow.o .libs/gdkpango.o = .libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o = .libs/gdkpolyreg-generic.o .libs/gdkrectangle.o = .libs/gdkregion-generic.o .libs/gdkrgb.o .libs/gdkscreen.o = .libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o = .libs/gdkwindowimpl.o .libs/gdkenumtypes.o .libs/gdkmarshalers.o = --whole-archive x11/.libs/libgdk-x11.a --no-whole-archive = -lpangocairo-1.0 -lpango-1.0 -lgio-2.0 -lfontconfig -lfreetype -lXrender = -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes = -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lcairo -lpthread -lX11 = -lXext -lm -soname libgdk-x11-2.0.so.0 -version-script = .libs/libgdk-x11-2.0.so.0.2400.29-ver -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtendS.o /usr/lib/crtn.o >> /usr/bin/ld: .libs/gdkcairo.o(.text+0x61c): unresolvable = R_ARM_MOVW_ABS_NC relocation against symbol `g_free' >> /usr/bin/ld: final link failed: Nonrepresentable section on output >> clang: error: linker command failed with exit code 1 (use -v to see = invocation) >> Makefile:1098: recipe for target 'libgdk-x11-2.0.la' failed >> gmake[6]: *** [libgdk-x11-2.0.la] Error 1 >> gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' >> Makefile:1238: recipe for target 'all-recursive' failed >> gmake[5]: *** [all-recursive] Error 1 >> gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' >> Makefile:1018: recipe for target 'all' failed >> gmake[4]: *** [all] Error 2 >> gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk' >> Makefile:729: recipe for target 'all-recursive' failed >> gmake[3]: *** [all-recursive] Error 1 >> gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29' >> Makefile:621: recipe for target 'all' failed >> gmake[2]: *** [all] Error 2 >> gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29' >> =3D=3D=3D> Compilation failed unexpectedly. >> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >> the maintainer. >> *** Error code 1 >=20 >=20 > Where the prior activity to produce .libs/gdkcairo.o was: >=20 >> /bin/sh ../libtool --tag=3DCC --mode=3Dcompile /usr/bin/clang -v = -target armv6--freebsd11.0-gnueabi -march=3Darmv7-a -mcpu=3Dcortex-a7 = -mfloat-abi=3Dsoftfp -mno-unaligned-access -DHAVE_CONFIG_H -I. -I.. = -DG_LOG_DOMAIN=3D\"Gdk\" -DGDK_COMPILATION -I.. -I.. -I../gdk = -DG_DISABLE_CAST_CHECKS -I/usr/local/include/glib-2.0 = -I/usr/local/lib/glib-2.0/include -I/usr/local/include = -I/usr/local/include/pango-1.0 -I/usr/local/include/cairo = -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 = -I/usr/local/include/libdrm -I/usr/local/include/libpng16 = -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/gdk-pixbuf-2.0 = -pthread -D_THREAD_SAFE -I/usr/local/include = -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES = -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES = -I/usr/local/include -D_THREAD_SAFE -pipe -mfloat-abi=3Dsoftfp -g = -fno-strict-aliasing -Wall -MT gdkcairo.lo -MD -MP -MF = .deps/gdkcairo.Tpo -c -o gdkcairo.lo gdkcairo.c >=20 > . . . >> "/usr/bin/clang" -cc1 -triple armv7--freebsd11.0-gnueabi -emit-obj = -mrelax-all -disable-free -main-file-name gdkcairo.c -mrelocation-model = static -mthread-model posix -mdisable-fp-elim -relaxed-alias >> ing -masm-verbose -mconstructor-aliases -target-cpu cortex-a7 = -target-feature +soft-float-abi -target-feature +strict-align = -target-abi aapcs-linux -mfloat-abi soft -v -dwarf-column-info = -debug-info-k >> ind=3Dstandalone -dwarf-version=3D2 -debugger-tuning=3Dgdb = -coverage-file = /usr/obj/portswork/usr/ports/x11-toolkits/gtk20/work/gtk+-2.24.29/gdk/gdkc= airo.c -resource-dir /usr/bin/../lib/clang/3.8.0 -dependen >> cy-file .deps/gdkcairo.Tpo -sys-header-deps -MP -MT gdkcairo.lo -D = HAVE_CONFIG_H -I . -I .. -D "G_LOG_DOMAIN=3D\"Gdk\"" -D GDK_COMPILATION = -I .. -I .. -I ../gdk -D G_DISABLE_CAST_CHECKS -I /usr/local/in >> clude/glib-2.0 -I /usr/local/lib/glib-2.0/include -I = /usr/local/include -I /usr/local/include/pango-1.0 -I = /usr/local/include/cairo -I /usr/local/include/pixman-1 -I = /usr/local/include/freetype2 -I /u >> sr/local/include/libdrm -I /usr/local/include/libpng16 -I = /usr/local/include/gio-unix-2.0/ -I /usr/local/include/gdk-pixbuf-2.0 -D = _THREAD_SAFE -I /usr/local/include -D G_DISABLE_SINGLE_INCLUDES -D AT >> K_DISABLE_SINGLE_INCLUDES -D GDK_PIXBUF_DISABLE_SINGLE_INCLUDES -D = GTK_DISABLE_SINGLE_INCLUDES -I /usr/local/include -D _THREAD_SAFE -Wall = -fdebug-compilation-dir /usr/obj/portswork/usr/ports/x11-tool >> kits/gtk20/work/gtk+-2.24.29/gdk -ferror-limit 19 -fmessage-length = 200 -pthread -fallow-half-arguments-and-returns -fno-signed-char = -fobjc-runtime=3Dgnustep -fdiagnostics-show-option -fcolor-diagnostics >> -o gdkcairo.o -x c gdkcairo.c > . . . >> libtool: compile: mv -f "gdkcairo.o" ".libs/gdkcairo.o" >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-10, at 3:55 AM, Mark Millard wrote: >=20 >=20 > On 2016-Jan-9, at 10:55 AM, Ian Lepore wrote: >>=20 >> On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >>> On 09 Jan 2016, at 04:46, Mark Millard = wrote: >>>>=20 >>>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric >>>> wrote: >>> ... >>>>> FYI, I have added a -mno-movt option for this purpose upstream, >>>>> and >>>>> imported a newer snapshot into the clang380-import branch. As of >>>>> r293384, it now uses the new option spelling for modules, if your >>>>> clang >>>>> is 3.8.0 or higher. >>>>>=20 >>>>> -Dimitry >>>>=20 >>>> I've not been able to get to the point of running clang++ 3.8 on >>>> the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations >>>> during the cross build's buildworld interfere. >>>=20 >>> Yes, this is caused by too large call distances. In other words, = the >>> clang executable is getting to big to link. Apparently we need to = do >>> some tricks with -mlongcall to fix this. As I am no arm expert, I >>> welcome any patch submissions. :-) >>>=20 >>> -Dimitry >>>=20 >>=20 >> Here's the patch I got from Andy for the clang380 branch, modified = with >> Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE. With >> this I can get a working arm world that will build a runnable >> helloworld.c (and .cc) on a dreamplug. (I.e., it appears clang 3.8.0 >> fixes the problem we had with clang 3.7.x where it wouldn't run at = all >> on armv4/5 systems). I have not tried compling anything complex yet. >>=20 >> -- Ian >=20 >=20 > Context: When I build I normally build lldb and the like as well, even = using WITH_CLANG_EXTRAS=3D . >=20 > In trying to get lldb to link I eventually get to the point that = libc++ is getting relocation truncations. Before getting to that I deal = with /usr/src/usr.bin/clang/lldb/Makefile to cover what is initially = reported during buildworld for lldb relocation truncations. Then with = that in place and retrying I get reports from libc++.a for a couple of = the contained .o files having relocations that are truncated (before it = reports "additional relocation overflows omitted from the output"): >=20 > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o) > /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o) >=20 > (Both have messages from multiple places in each .o file.) >=20 > As far as I can tell for general use -long-calls is going to be needed = for at least some system level .a library content if the .a's are to be = used. >=20 > Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for = arm system libraries fairly generally is appropriate for those intending = on building the arm-native clang toolchain and related material in = buildworld. (STATIC_CFLAGS too?) A significant case analysis of what = happens to currently be too far apart would be fragile as things grow = even more later. >=20 > This sort of issue may well not be limited to TARGET=3Darm contexts. >=20 > The detailed libc++.a relocation truncation complaints that I got = were: >=20 >=20 >> --- all_subdir_lldb --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hi= dden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocat= orIS6_EEE21__push_back_slow_pathIS6_EEvOT_[_ZNSt3__16vectorINS_4pairIPNS_1= 8condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_ba= ck_slow_pathIS6_EEvOT_]+0x30): relocation truncated to fit: R_ARM_CALL = against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In = function = `_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21= __push_back_slow_pathIRKS2_EEvOT_': >> = /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16v= ectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_= slow_pathIRKS2_EEvOT_[_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidd= en_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_]+0x30): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__vector_base_common::__throw_length_error() const' = defined in = .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKS= t3__120__vector_base_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 > . . . >> --- all_subdir_clang --- >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(char const*, char = const*, char const*, char const*) const': > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x81ec): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) > . . . >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x82c0): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8430): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_compare(wchar_t const*, = wchar_t const*, wchar_t const*, wchar_t const*) const': >=20 >> --- all_subdir_clang --- >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x88a8): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x899c): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate_byname::do_transform(wchar_t = const*, wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text+0x8b34): = relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(char const*, char = const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIcE12do_transformEPKcS3_[_ZNKSt3__17collateIcE12do_transformEPKcS3_= ]+0x34): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::collate::do_transform(wchar_t const*, = wchar_t const*) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= collateIwE12do_transformEPKwS3_[_ZNKSt3__17collateIwE12do_transformEPKwS3_= ]+0x38): relocation truncated to fit: R_ARM_CALL against symbol = `std::__1::__basic_string_common::__throw_length_error() const' = defined in = .text._ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv[_ZNK= St3__121__basic_string_commonILb1EE20__throw_length_errorEv] section in = /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/lib= lldbCore/liblldbCore.a(CxaDemangle.o) >=20 >> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In = function `std::__1::num_put > = >::do_put(std::__1::ostreambuf_iterator >, std::__1::ios_base&, char, long) const': >> = /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp:(.text._ZNKSt3__17= num_putIcNS_19ostreambuf_iteratorIcNS_11char_traitsIcEEEEE6do_putES4_RNS_8= ios_baseEcl[_ZNKSt3__17num_putIcNS_19ostreambuf_iteratorIcNS_11char_traits= IcEEEEE6do_putES4_RNS_8ios_baseEcl]+0x16c): additional relocation = overflows omitted from the output >=20 >=20 > Ian's/Andy's original patch is listed below for reference. >=20 >> Index: lib/clang/clang.lib.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/clang/clang.lib.mk (revision 293584) >> +++ lib/clang/clang.lib.mk (working copy) >> @@ -6,4 +6,8 @@ LLVM_SRCS=3D ${.CURDIR}/../../../contrib/llvm >>=20 >> INTERNALLIB=3D >>=20 >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +STATIC_CXXFLAGS+=3D-mlong-calls >> +.endif >> + >> .include >> Index: lib/csu/arm/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- lib/csu/arm/Makefile (revision 293584) >> +++ lib/csu/arm/Makefile (working copy) >> @@ -23,7 +23,7 @@ CLEANFILES+=3D crt1.s gcrt1.s Scrt1.s >> # directly compiled to .o files. >>=20 >> crt1.s: crt1.c >> - ${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> crt1.o: crt1.s >> @@ -30,7 +30,7 @@ crt1.o: crt1.s >> ${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s >>=20 >> gcrt1.s: crt1.c >> - ${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c >> + ${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} = ${.CURDIR}/crt1.c >> sed ${SED_FIX_NOTE} ${.TARGET} >>=20 >> gcrt1.o: gcrt1.s >> Index: usr.bin/clang/clang/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- usr.bin/clang/clang/Makefile (revision 293584) >> +++ usr.bin/clang/clang/Makefile (working copy) >> @@ -11,7 +11,11 @@ SRCS=3D cc1_main.cpp \ >>=20 >> .if ${MK_SHARED_TOOLCHAIN} =3D=3D "no" >> NO_SHARED?=3D yes >> + >> +.if ${MACHINE_CPUARCH} =3D=3D "arm" >> +CFLAGS+=3D-mlong-calls >> .endif >> +.endif >>=20 >> LINKS=3D ${BINDIR}/clang ${BINDIR}/clang++ \ >> ${BINDIR}/clang ${BINDIR}/clang-cpp >>=20 >=20 From owner-freebsd-arm@freebsd.org Mon Jan 11 13:01:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DC3AA693DF for ; Mon, 11 Jan 2016 13:01:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 47BBE1087 for ; Mon, 11 Jan 2016 13:01:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0BD1Jjb075508 for ; Mon, 11 Jan 2016 13:01:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 205904] textproc/expat2: unresolvable R_ARM_MOVW_ABS_NC relocation against symbol `malloc@@FBSD_1.0' Date: Mon, 11 Jan 2016 13:01:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:01:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205904 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Not A Bug --- Comment #3 from Mark Millard --- Looks like using -v on clang/clang++ command lines messes up autoconf/libto= ol figuring things out: I had -v in the $(CC) and $(CXX) text. The overall result was that -fpic/-fPIC and the like were not being used because of teh options being classified as not-available. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Jan 12 06:18:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48A3BA6CEED for ; Tue, 12 Jan 2016 06:18:09 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [91.199.228.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09D311BBB for ; Tue, 12 Jan 2016 06:18:08 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from 46-253-187-21.dynamic.monzoon.net ([46.253.187.21] helo=fluff-wlan.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1aIroM-000IFA-Ip for freebsd-arm@freebsd.org; Tue, 12 Jan 2016 06:48:12 +0100 Message-ID: <56949397.6010906@fsck.ch> Date: Tue, 12 Jan 2016 06:48:07 +0100 From: Toby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Cannot build RBPI2 kernel on pi References: <567718A1.7040900@fsck.ch> In-Reply-To: <567718A1.7040900@fsck.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 20/12/15 22:07, Toby wrote: > make buildkernel KENRCONF=RPI2 fails with the following error: > > > ERROR: ctfmerge: No ctf sections found to merge > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk if_de.kld export_syms | xargs > -J% objcopy % if_de.kld > ld -Bshareable -d -warn-common -o if_de.ko if_de.kld > objcopy --strip-debug if_de.ko > ===> dtb/rpi (all) > Generating rpi.dtb from rpi.dts > converting rpi.dts -> > /usr/obj/usr/src/sys/RPI2/modules/usr/src/sys/modules/dtb/rpi/rpi.dtb > Unable to open file ./bcm2835.dtsi > Segmentation fault (core dumped) > *** Error code 139 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 46.253.187.21 X-SA-Exim-Mail-From: misc.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 06:18:09 -0000 On 20/12/15 22:07, Toby wrote: > make buildkernel KENRCONF=RPI2 fails with the following error: > > > ERROR: ctfmerge: No ctf sections found to merge > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk if_de.kld export_syms | xargs > -J% objcopy % if_de.kld > ld -Bshareable -d -warn-common -o if_de.ko if_de.kld > objcopy --strip-debug if_de.ko > ===> dtb/rpi (all) > Generating rpi.dtb from rpi.dts > converting rpi.dts -> > /usr/obj/usr/src/sys/RPI2/modules/usr/src/sys/modules/dtb/rpi/rpi.dtb > Unable to open file ./bcm2835.dtsi > Segmentation fault (core dumped) > *** Error code 139 So, am I the only one with this problem? I just tried again with a new checkout and still the same error when building the kernel on my pi. Is this supposed to work, or am I forced to cross-compile? I remember having read on the list that some people compile the kernel with success directly on their pi. Thanks, Toby From owner-freebsd-arm@freebsd.org Tue Jan 12 15:04:25 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CF19A6D842 for ; Tue, 12 Jan 2016 15:04:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 517821A8A; Tue, 12 Jan 2016 15:04:25 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 32D5F1A92; Tue, 12 Jan 2016 15:04:22 +0000 (UTC) Date: Tue, 12 Jan 2016 15:03:21 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: arybchik@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1043636966.17.1452611057254.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <632077003.15.1452601404130.JavaMail.jenkins@jenkins-9.freebsd.org> References: <632077003.15.1452601404130.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2121 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:04:25 -0000 FreeBSD_HEAD_arm64 - Build #2121 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2121/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2121/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2121/console Change summaries: 293758 by arybchik: sfxge: remove obsolete common code PKTFILTER module The pktfilter module has been obsolete for some time, as it was replaced by newer features in filter module. With the removal of the storport driver, this module has no users and can be removed. Submitted by: Andy Moreton Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4875 293757 by arybchik: sfxge: rename hunt MCDI methods to ef10 and use for Medford Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4874 293756 by arybchik: sfxge: rename hunt nvram methods and use for Medford Some new partitions have been added, but they shouldn't need to be handled any differently. Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4873 293755 by arybchik: sfxge: rename Huntington VPD methods to ef10 and use for Medford Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4872 293754 by arybchik: sfxge: rename hunt RX methods to ef10 and use for Medford Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4871 293753 by arybchik: sfxge: rename hunt TX methods to ef10 and use for Medford Rename all except hunt_tx_qdesc_tso_create(), which creates a fw-assisted TSO v1 descriptor which isn't supported on Medford. Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4870 293752 by arybchik: sfxge: rename hunt ev methods to ef10 and use for Medford Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4869 293751 by arybchik: sfxge: rename hunt interrupt methods to ef10 and use on Medford All of these apply to both Huntington and Medford. Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4868 293750 by arybchik: sfxge: update SRAM methods to be no-ops on Medford as well Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4867 293749 by arybchik: sfxge: use NIC config in place of some Huntington specific PIO constants This should allow these functions to work for Medford as well. Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4866 293748 by arybchik: sfxge: change hunt specific fields of efx_nic_t to ef10 All these fields will be used in shared ef10 code, so put them in an ef10 member of a per-architecture union, rather that in the per-chip union. Submitted by: Mark Spender Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4865 From owner-freebsd-arm@freebsd.org Tue Jan 12 16:47:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB046A80A32 for ; Tue, 12 Jan 2016 16:47:35 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6615F116E for ; Tue, 12 Jan 2016 16:47:35 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id f206so260574027wmf.0 for ; Tue, 12 Jan 2016 08:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=XzscI3gY9pSelg/p/8bs0sxshtzN4W5j03xXQ8LtWy8=; b=yLxsqJRVMR7H0G56/Lst+zifNIosP/emj0jgpPckHnc7adugCOBJPRx27UeO4sJKrE CUo0HFmZpj2Wp4CkPdeh1yNdhi9RS2tmGOpDOPivRhZ5Z0AfjeHgbO0aONlC3EENfkOi 2zTreWEUPjs4jnMGGr/9samsSBomRi21j2bTnGBQntZNi04QT4gBbPbIZENvAAILuT5r Ut8mK5tkZ6ntibEe7wT1FZ5exyOoucndnWZMc/50viJuy1dt7gRZi4Xjo6PKQANpGZiP VPQPyr8gDysOuQGCICXndzsAKWb1Xy8INHtg6z3C/FtqBugNKySQxoU3evn+uB4SYHkK VC+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=XzscI3gY9pSelg/p/8bs0sxshtzN4W5j03xXQ8LtWy8=; b=l6jhAmgkJcx8JbhMbXBWgpUVzbO8dF6WjwTKxGGfCDGA6hnHrsGmeO8yHueRlGSue+ fxeKMe9PrPqVeG3cV4JWbdRBg34nHQFLIgb1b0ZY7tqx+zYEuO6YOV940rTpnfsrbWv9 nzYicHeBIZ6WU+gheeoX3c6C3/lqp9ff/VMqr6+ay9BgvtsFxIqj/RW8MUbT2c93ZecR mEh8OPNdKvnkHqyOsQlPZUeHe+gGDc339P48+XwxAlI5OjszzsAIM7nx0mH7YFpwiJYy LgGrSWJrbR9RTI4DQqemf8s1BcwnvWflTBifFP0U6cY7Xv9ocX9vkB7DU6IKSFndXtdn b6IQ== X-Gm-Message-State: ALoCoQldCiYIh31FttJKIOdnksDxksC53xoOm+NJ676ky5ccF9djb7D9SARJ2u9iNebJKFHQFNM9KMsgIVLwVRwMEUJ5v3ntog== X-Received: by 10.28.141.10 with SMTP id p10mr20017819wmd.83.1452617253957; Tue, 12 Jan 2016 08:47:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Vijlbrief Date: Tue, 12 Jan 2016 16:47:24 +0000 Message-ID: Subject: Re: Re: Cannot build RBPI2 kernel on pi (Toby) To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:47:35 -0000 > > > > On 20/12/15 22:07, Toby wrote: > > > make buildkernel KENRCONF=RPI2 fails with the following error: > > > > > > ERROR: ctfmerge: No ctf sections found to merge > > :> export_syms > > awk -f /usr/src/sys/conf/kmod_syms.awk if_de.kld export_syms | xargs > > -J% objcopy % if_de.kld > > ld -Bshareable -d -warn-common -o if_de.ko if_de.kld > > objcopy --strip-debug if_de.ko > > ===> dtb/rpi (all) > > Generating rpi.dtb from rpi.dts > > converting rpi.dts -> > > /usr/obj/usr/src/sys/RPI2/modules/usr/src/sys/modules/dtb/rpi/rpi.dtb > > Unable to open file ./bcm2835.dtsi > > Segmentation fault (core dumped) > > *** Error code 139 > > So, am I the only one with this problem? I just tried again with a new > checkout and still the same error when building the kernel on my pi. Is > this supposed to work, or am I forced to cross-compile? I remember > having read on the list that some people compile the kernel with success > directly on their pi. > > Thanks, > Toby > > Building on the Raspberry works OK for me with 11-CURRENT. Did you do a make buildworld before "make buildkernel"? Tom From owner-freebsd-arm@freebsd.org Tue Jan 12 21:22:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95ADBA80BB0 for ; Tue, 12 Jan 2016 21:22:21 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 39C2B119C for ; Tue, 12 Jan 2016 21:22:20 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id u0CLMHUU009253 for ; Tue, 12 Jan 2016 22:22:18 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 12 Jan 2016 22:22:17 +0100 (CET) Message-ID: <47893d8835f.5a36239a@mail.schwarzes.net> In-Reply-To: <56949397.6010906@fsck.ch> References: <567718A1.7040900@fsck.ch> <56949397.6010906@fsck.ch> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Cannot build RBPI2 kernel on pi MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Tue, 12 Jan 2016 22:22:18 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:22:21 -0000 On 12.01.16, Toby wrote: > On 20/12/15 22:07, Toby wrote: Hi Toby, >> make buildkernel KENRCONF=RPI2 fails with the following error: >> >> >> ERROR: ctfmerge: No ctf sections found to merge >> :> export_syms >> awk -f /usr/src/sys/conf/kmod_syms.awk if_de.kld export_syms | xargs >> -J% objcopy % if_de.kld >> ld -Bshareable -d -warn-common -o if_de.ko if_de.kld >> objcopy --strip-debug if_de.ko >> ===> dtb/rpi (all) >> Generating rpi.dtb from rpi.dts >> converting rpi.dts -> >> /usr/obj/usr/src/sys/RPI2/modules/usr/src/sys/modules/dtb/rpi/rpi.dtb >> Unable to open file ./bcm2835.dtsi >> Segmentation fault (core dumped) >> *** Error code 139 > > So, am I the only one with this problem? I just tried again with a new > checkout and still the same error when building the kernel on my pi. Is > this supposed to work, or am I forced to cross-compile? I remember > having read on the list that some people compile the kernel with success > directly on their pi. I just build a new world (r293653) at my RPI2, all is working like expected. Is your source tree complete and up to date? You can check this with "svnlite status". And what is your building procedure? The proper procedure is to build the kernel-toolchain before building the kernel (this is needed when the build tools changing). -asc From owner-freebsd-arm@freebsd.org Wed Jan 13 09:54:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D20DFA8192F for ; Wed, 13 Jan 2016 09:54:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C2E8B1E4D for ; Wed, 13 Jan 2016 09:54:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0D9sMII004127 for ; Wed, 13 Jan 2016 09:54:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 198783] I2C driver for AM335X enhancement Date: Wed, 13 Jan 2016 09:54:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: manu@bidouilliste.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:54:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D198783 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Works As Intended Status|New |Closed --- Comment #2 from Emmanuel Vadot --- Closing this bug as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D198= 817 implement I2C_RDRW in i2c(8) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Jan 13 20:11:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DDECA81455 for ; Wed, 13 Jan 2016 20:11:45 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [91.199.228.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4E3F100E for ; Wed, 13 Jan 2016 20:11:44 +0000 (UTC) (envelope-from misc.lists@fsck.ch) Received: from 46-253-187-21.dynamic.monzoon.net ([46.253.187.21] helo=fluff-wlan.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83 (FreeBSD)) (envelope-from ) id 1aJRlQ-000Acu-QZ for freebsd-arm@freebsd.org; Wed, 13 Jan 2016 21:11:35 +0100 Message-ID: <5696AF70.2030901@fsck.ch> Date: Wed, 13 Jan 2016 21:11:28 +0100 From: Toby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Cannot build RBPI2 kernel on pi References: <567718A1.7040900@fsck.ch> <56949397.6010906@fsck.ch> <47893d8835f.5a36239a@mail.schwarzes.net> In-Reply-To: <47893d8835f.5a36239a@mail.schwarzes.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/01/16 22:22, Andreas Schwarz wrote: > I just build a new world (r293653) at my RPI2, all is working like expected. > > Is your source tree complete and up to date? You can check this with "svnlite status". > > And what is your building procedure? The proper procedure is to build the > kernel-toolchain before building the kernel (this is needed when the build > tools changing). [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-SA-Exim-Connect-IP: 46.253.187.21 X-SA-Exim-Mail-From: misc.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:11:45 -0000 On 12/01/16 22:22, Andreas Schwarz wrote: > I just build a new world (r293653) at my RPI2, all is working like expected. > > Is your source tree complete and up to date? You can check this with "svnlite status". > > And what is your building procedure? The proper procedure is to build the > kernel-toolchain before building the kernel (this is needed when the build > tools changing). On 12/01/16 17:47, Tom Vijlbrief wrote: > Building on the Raspberry works OK for me with 11-CURRENT. > > Did you do a > > make buildworld > > before "make buildkernel"? > > Tom Bummer! I totally forgot to do a buildworld to get the toolchain before building the kernel. I didn't even bother to look at the handbook, because in the past, I have done this countless times and knew the procedure by heart. But I guess that past is now too distant (the last time I did this probably was right before freebsd-update was introduced). Anyway, thanks a lot for this hint to both of you, I'll try it again tonight. Toby From owner-freebsd-arm@freebsd.org Wed Jan 13 20:25:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2AD8A8181B for ; Wed, 13 Jan 2016 20:25:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 D7DF01807 for ; Wed, 13 Jan 2016 20:25:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 13 Jan 2016 20:25:45 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u0DKP7VV008040; Wed, 13 Jan 2016 13:25:07 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1452716707.46848.53.camel@freebsd.org> Subject: Re: Cannot build RBPI2 kernel on pi From: Ian Lepore To: Toby , freebsd-arm@freebsd.org Date: Wed, 13 Jan 2016 13:25:07 -0700 In-Reply-To: <5696AF70.2030901@fsck.ch> References: <567718A1.7040900@fsck.ch> <56949397.6010906@fsck.ch> <47893d8835f.5a36239a@mail.schwarzes.net> <5696AF70.2030901@fsck.ch> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 20:25:10 -0000 On Wed, 2016-01-13 at 21:11 +0100, Toby wrote: > On 12/01/16 22:22, Andreas Schwarz wrote: > > I just build a new world (r293653) at my RPI2, all is working like > > expected. > > > > Is your source tree complete and up to date? You can check this > > with "svnlite status". > > > > And what is your building procedure? The proper procedure is to > > build the > > kernel-toolchain before building the kernel (this is needed when > > the build > > tools changing). > > On 12/01/16 17:47, Tom Vijlbrief wrote: > > Building on the Raspberry works OK for me with 11-CURRENT. > > > > Did you do a > > > > make buildworld > > > > before "make buildkernel"? > > > > Tom > > > Bummer! I totally forgot to do a buildworld to get the toolchain > before > building the kernel. I didn't even bother to look at the handbook, > because in the past, I have done this countless times and knew the > procedure by heart. But I guess that past is now too distant (the > last > time I did this probably was right before freebsd-update was > introduced). > > Anyway, thanks a lot for this hint to both of you, I'll try it again > tonight. > > Toby If you don't really need the whole world you can save some time by using make kernel-toolchain. -- Ian From owner-freebsd-arm@freebsd.org Thu Jan 14 08:39:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E43C3A82A72 for ; Thu, 14 Jan 2016 08:39:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 D57ED12BA for ; Thu, 14 Jan 2016 08:39:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0E8dTsR007646 for ; Thu, 14 Jan 2016 08:39:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 206229] [patch] Move Atmel's USB OHCI controller FDT driver Date: Thu, 14 Jan 2016 08:39:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sgalabov@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 08:39:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229 Bug ID: 206229 Summary: [patch] Move Atmel's USB OHCI controller FDT driver Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: sgalabov@gmail.com Keywords: patch Created attachment 165548 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D165548&action= =3Dedit Move Atmel's USB OHCI controller FDT driver Currently, the at91 specific USB OHCI driver is named simply ohci_fdt.c, wh= ich is misleading and does not leave space for an attempt at a generic ohci_fdt implementation (e.g., possibly based on the dwc_otg FDT support). The attached patch renames ohci_fdt.c to at91ohci_fdt.c in sys/dev/usb/controller and also replaces the reference to ohci_fdt.c in sys/arm/at91/files.at91 with at91ohci_fdt.c. Once/if a generic OHCI FDT driver is added, the at91 specific one may be retired if at91 can use the generic one. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Jan 14 09:01:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 353FBA819A6; Thu, 14 Jan 2016 09:01:14 +0000 (UTC) (envelope-from sgalabov@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E299B138D; Thu, 14 Jan 2016 09:01:13 +0000 (UTC) (envelope-from sgalabov@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b14so417585257wmb.1; Thu, 14 Jan 2016 01:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=yJb13U2oeLhCUD+3A7yiViQhRldmeJIcnZrHNKg3xhU=; b=gzSNuWuHf5Q7SZf5fxI+7Gj4GXOrv6bQY5NHLYqjMg6EP9m2Esm2RmY67u0m3PBS71 HXOQKbb/S2qLGKbPeW1SuC5uo25UvserUxXcgklOtA7HbVoRS9EYJ2WULjEhHlDIx2u7 sV2HYZRWnb1zh3h/T2GoHbCL6bArU5OC6wVQFmI1z+nTavJpsppqiyQ0cIwxK29Er8cU EqXbacvzmUzd9V8h4XxwgJYHq5GMkCVIyuxRujhr2wdbLxbd6qxASNNkoIpTmP8XqLMs kTsr1pUYZ7it0UK305sXdc5rNCPyaeYpgJH2cT2TdkKygvANPsCESp5z4iuQAZPBY/2h Nbhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=yJb13U2oeLhCUD+3A7yiViQhRldmeJIcnZrHNKg3xhU=; b=ayJAwbQFwP5MfLCSNoH9D+VcGeOjOvrIqd2AgYTEO4EQ/8NZuBrAfjGTnYtKcO/h01 WayhsK7QHn1GqQ4aJmaymNKuS0cATwh+s08IM7aMQuKGW6Us/FxmN5xQEfYZHlzHgJlS tn/uwzA7MCGBysFOOekD4roumWLbx+u9ExasW5oX6vaIYEVFW0Rozf4c7zMq6lVE2gca IvLBjpb63jr2/WZyXL5hoh1W1gXGPnuVbq5T1USxn7iyUO4J91plqIu9jxVCmPEInNyP kQPIelY3upZMsiisPPB1Wg2jdBqP2eLnMFpgdCV3iHm1YbWtYVpl3aRnXfLLmsmZwPjT ApSQ== X-Gm-Message-State: ALoCoQkNnsjgYp5GOYLoV24kl9SFQKoH4pVOr25pDlKPG6YLTr8AbpP4cvKXBL803BilTCj1PV98f7u+7gB5/TJ7JnXqw8Q87w== X-Received: by 10.195.13.129 with SMTP id ey1mr2690540wjd.132.1452762071916; Thu, 14 Jan 2016 01:01:11 -0800 (PST) Received: from macbookpro-894a.hsmt ([193.178.153.131]) by smtp.gmail.com with ESMTPSA id t76sm6288532wmd.13.2016.01.14.01.01.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Jan 2016 01:01:11 -0800 (PST) From: Stanislav Galabov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: SPI geom_flashmap/fdt_slicer support, FDT 'resets=' support and a move of ohci_fdt.c Date: Thu, 14 Jan 2016 11:01:10 +0200 Message-Id: To: freebsd-mips@freebsd.org, freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Mailer: Apple Mail (2.3094) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 09:01:14 -0000 Hi all, First off, sorry for the cross-post, I wasn=E2=80=99t very sure where = this should go=E2=80=A6 I=E2=80=99ve created 3 PRs, which enable some functionality that my work = on Ralink/Mediatek SoCs would benefit from. 1. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206227 - This enables geom_flashmap and fdt_slicer support for SPI flash chips = supported by the mx25l driver (sys/dev/flash/mx25l.c) 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206228 - This adds support for FDT =E2=80=98resets=3D=E2=80=99 property in much = the same way as ian@=E2=80=99s sys/dev/fdt/fdt_clock* supports FDT = =E2=80=98clocks=3D=E2=80=98 property. In fact this work is basically a = modified version of fdt_clock* :-) 3. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229 - This simply moves the at91 specific sys/dev/usb/controller/ohci_fdt.c = to sys/dev/usb/controller/at91ohci_fdt.c (and changes the filename in = sys/arm/at91/files.at91 as well). The current naming is misleading IMHO = and also, I have some (vague-ish) plans to see if I can implement = generic ohci_fdt and ehci_fdt based on dwc_otg_fdt, so that systems with = standard ehci/ohci controllers can reuse these. Patches are attached to the PRs. I would appreciate any feedback on the PRs and would also appreciate it = if someone could commit these if the proposed changes are appropriate. Best wishes, Stanislav= From owner-freebsd-arm@freebsd.org Fri Jan 15 08:23:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 728FDA83822 for ; Fri, 15 Jan 2016 08:23:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 306302124 for ; Fri, 15 Jan 2016 08:23:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aJzVs-000Phy-KC for freeBSD-arm@freebsd.org; Fri, 15 Jan 2016 10:13:40 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: cross compiling for rpi2 Message-Id: Date: Fri, 15 Jan 2016 10:13:40 +0200 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 08:23:23 -0000 Hi, with the latest current I=E2=80=99m getting: =E2=80=A6 linking kernel.full cam_periph.o: In function `cam_periph_alloc': /r+d/vanilla/11/src/sys/cam/cam_periph.c:258: undefined reference to = `DELAY' /r+d/vanilla/11/src/sys/cam/cam_periph.c:271: undefined reference to = `DELAY' cam_periph.o: In function `camperiphfree': /r+d/vanilla/11/src/sys/cam/cam_periph.c:680: undefined reference to = `DELAY' cam_periph.o: In function `cam_periph_invalidate': /r+d/vanilla/11/src/sys/cam/cam_periph.c:610: undefined reference to = `DELAY' cam_xpt.o: In function `xpt_run_devq': /r+d/vanilla/11/src/sys/cam/cam_xpt.c:3294: undefined reference to = `DELAY' cam_xpt.o:/r+d/vanilla/11/src/sys/cam/cam_xpt.c:3035: more undefined = references to `DELAY' follow *** Error code 1 is there a quick fix?= From owner-freebsd-arm@freebsd.org Fri Jan 15 19:39:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48D03A8494A for ; Fri, 15 Jan 2016 19:39:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D79D1136 for ; Fri, 15 Jan 2016 19:39:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk0-x22d.google.com with SMTP id q19so266598877qke.3 for ; Fri, 15 Jan 2016 11:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i8jNLc99PClgJfyC3xH3QNmJl2TCtPUuvPukziiHG1s=; b=vQwdDmk7n//SdRbnJ+xk0UN51ous0ub4eB1PKknIYl2KkEY5/DxSL67wEk+rOBYubx p8/deu4NevDs7MkioFqkLwfpuEHXUbWfC4ZwiIUG3pRreCmoCHAmxHKSXcA6I6/rxtli OWdtNE7zdvKTaAtdYLzRyV6lHHO3OFb5+PDnWviwIb42UOVcn7B7Kdm0DkjpBghwE3xC +TCnXhMpAIG6NX6fB4nElnQGivQOWZIHbdSxp0dihqa8KeYzM/VBrAY8x1Y54P+H6mS2 UNygrhV9AK0wypvd/tITm5hX17NMaNqGQ5eQ2LLUSZihHklsCmp5eCeQnyoyHx025ikA +hUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i8jNLc99PClgJfyC3xH3QNmJl2TCtPUuvPukziiHG1s=; b=bRH5uEFUq6eSwP3jw3s1dIRzaNCN621osdfc1ElCTZrKlcpDjRxvN0IQ/bsDxKFBFh fsOAJfH4H9ISIv+Ju//bkzMrtlf6xCodeoyeyZkJb+NLnerKNG/b30l++Itf14ULEQ4E nwPVoJSRPU5yhAmZTbDaNbaIdhabviSiMZHGZIWB5chqo7nFjpuN2/xM0F/XTKczid4i wN87g8TqHTk4O8kpwakmiGkYfSZB9JYlVAcYFjqUOS+JFm1WiBPd1PcmHvmSnirzq7H4 sr5+wr1cxXjWHkczugV6EjvKENomojtsm2b2CFYHQScIKPPOCeiIuZr3OrXU/Ha8oYgC uCQQ== X-Gm-Message-State: ALoCoQn5t/srvSRhMkAr5zWMMRxCwFbba0GMvT1e5aHK03+Kdv7xUf4CdPNv+wDCmxX0R9BP0Qmuys133BGXgeSPh4GGSeUTPw== MIME-Version: 1.0 X-Received: by 10.55.40.160 with SMTP id o32mr15411323qko.93.1452886782882; Fri, 15 Jan 2016 11:39:42 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Fri, 15 Jan 2016 11:39:42 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Fri, 15 Jan 2016 12:39:42 -0700 X-Google-Sender-Auth: 67JSG32OPSfSMPcykC5_BFBtgwg Message-ID: Subject: Re: cross compiling for rpi2 From: Warner Losh To: Daniel Braniss Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 19:39:44 -0000 I didn't get those when I built head last night. Nor when I built this morning. Warner On Fri, Jan 15, 2016 at 1:13 AM, Daniel Braniss wrote= : > Hi, > with the latest current I=E2=80=99m getting: > =E2=80=A6 > linking kernel.full > cam_periph.o: In function `cam_periph_alloc': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:258: undefined reference to > `DELAY' > /r+d/vanilla/11/src/sys/cam/cam_periph.c:271: undefined reference to > `DELAY' > cam_periph.o: In function `camperiphfree': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:680: undefined reference to > `DELAY' > cam_periph.o: In function `cam_periph_invalidate': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:610: undefined reference to > `DELAY' > cam_xpt.o: In function `xpt_run_devq': > /r+d/vanilla/11/src/sys/cam/cam_xpt.c:3294: undefined reference to `DELAY= ' > cam_xpt.o:/r+d/vanilla/11/src/sys/cam/cam_xpt.c:3035: more undefined > references to `DELAY' follow > *** Error code 1 > > is there a quick fix? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Jan 15 22:15:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19A98A83EF8 for ; Fri, 15 Jan 2016 22:15:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-3.reflexion.net [208.70.210.3]) (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 A7CE81A32 for ; Fri, 15 Jan 2016 22:15:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19044 invoked from network); 15 Jan 2016 22:15:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Jan 2016 22:15:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 15 Jan 2016 17:15:28 -0500 (EST) Received: (qmail 13704 invoked from network); 15 Jan 2016 22:15:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 15 Jan 2016 22:15:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.124] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 911E31C43CA; Fri, 15 Jan 2016 14:15:20 -0800 (PST) From: Mark Millard Date: Fri, 15 Jan 2016 14:15:24 -0800 Subject: base/projects/clang3.8.0-import -r294096 buildworld targeting arm (for rpi2): assertion failed To: freebsd-arm , FreeBSD Toolchain Message-Id: <47CFB052-427F-4456-8759-DBB71BA087F9@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 22:15:33 -0000 My attempted buildworld of -r294096 from amd64 targeting arm for an rpi2 = stopped with: > --- all_subdir_usr.sbin --- > Assertion failed: (Offset <=3D PieceOffset && "overlapping or = duplicate pieces"), function finalize, file = /usr/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/Asm= Printer/DwarfDebug.cpp, line 1561. . . . > --- all_subdir_usr.sbin --- > clang: note: diagnostic msg:=20 > ******************** >=20 > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > clang: note: diagnostic msg: /tmp/parser-392d84.c > clang: note: diagnostic msg: /tmp/parser-392d84.sh > clang: note: diagnostic msg:=20 >=20 > ******************** > *** [parser.o] Error code 254 >=20 > make[4]: stopped in /usr/src/usr.sbin/nscd > 1 error Detailed context: make.conf: empty. src.conf: > TO_TYPE=3Darmv6 > # > KERNCONF=3DRPI2-NODBG > TARGET=3Darm > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BINTOOLS_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > WITH_CLANG_EXTRAS=3D > WITH_BOOT=3D > # > WITHOUT_LIB32=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG=3D > WITH_DEBUG_FILES=3D > # > .if ${.MAKE.LEVEL} =3D=3D 0 > XCC=3D/usr/bin/clang -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCXX=3D/usr/bin/clang++ -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > XCPP=3D/usr/bin/clang-cpp -v -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access > .export XCC > .export XCXX > .export XCPP > .endif > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang -v > CXX=3D/usr/bin/clang++ -v > CPP=3D/usr/bin/clang-cpp -v > .export CC > .export CXX > .export CPP > .endif RPI2-NODBG: ident RPI2-NODBG >=20 > include "RPI2" >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols > options ALT_BREAK_TO_DEBUGGER > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jan 15 22:22:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E2E1A84145; Fri, 15 Jan 2016 22:22:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 552671EA9; Fri, 15 Jan 2016 22:22:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::4409:1b0:7257:9b68] (unknown [IPv6:2001:7b8:3a7:0:4409:1b0:7257:9b68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D94222D56E; Fri, 15 Jan 2016 23:22:10 +0100 (CET) Subject: Re: base/projects/clang3.8.0-import -r294096 buildworld targeting arm (for rpi2): assertion failed Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2DE0FE60-F473-4D20-A9A1-9059910F9506"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <47CFB052-427F-4456-8759-DBB71BA087F9@dsl-only.net> Date: Fri, 15 Jan 2016 23:24:05 +0100 Cc: freebsd-arm , FreeBSD Toolchain Message-Id: <243ABE58-4FB6-4990-9582-20820F3F57A8@FreeBSD.org> References: <47CFB052-427F-4456-8759-DBB71BA087F9@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 22:22:14 -0000 --Apple-Mail=_2DE0FE60-F473-4D20-A9A1-9059910F9506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Jan 2016, at 23:15, Mark Millard wrote: >=20 > My attempted buildworld of -r294096 from amd64 targeting arm for an = rpi2 stopped with: >=20 >> --- all_subdir_usr.sbin --- >> Assertion failed: (Offset <=3D PieceOffset && "overlapping or = duplicate pieces"), function finalize, file = /usr/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/Asm= Printer/DwarfDebug.cpp, line 1561. Yes, this is a pretty new assertion. It's reported upstream by Andrew = here: https://llvm.org/bugs/show_bug.cgi?id=3D26163 I'm currently bisecting where this started appearing. I'll make sure to = inform the person who caused it. :) -Dimitry --Apple-Mail=_2DE0FE60-F473-4D20-A9A1-9059910F9506 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlaZcY4ACgkQsF6jCi4glqN90wCeKmf1VgO+TdRIh7h6sYOH8ELh fWIAoOY8tc0yz2eORRU6Eb+No9/d9Nmq =WZHi -----END PGP SIGNATURE----- --Apple-Mail=_2DE0FE60-F473-4D20-A9A1-9059910F9506-- From owner-freebsd-arm@freebsd.org Fri Jan 15 22:22:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3592EA841C0 for ; Fri, 15 Jan 2016 22:22:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 2682C1F4F for ; Fri, 15 Jan 2016 22:22:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0FMMp6j055438 for ; Fri, 15 Jan 2016 22:22:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 206299] base/projects/clang3.8.0-import -r294096 buildworld targeting arm (for rpi2): assertion failed Date: Fri, 15 Jan 2016 22:22:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 22:22:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206299 Bug ID: 206299 Summary: base/projects/clang3.8.0-import -r294096 buildworld targeting arm (for rpi2): assertion failed Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net Created attachment 165644 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D165644&action= =3Dedit .zip of the the .sh and .c that clang generated for the report. My attempted buildworld of -r294096 from amd64 targeting arm for an rpi2 stopped with: --- all_subdir_usr.sbin --- Assertion failed: (Offset <=3D PieceOffset && "overlapping or duplicate pie= ces"), function finalize, file /usr/src/lib/clang/libllvmasmprinter/../../../contrib/llvm/lib/CodeGen/AsmP= rinter/DwarfDebug.cpp, line 1561. . . . --- all_subdir_usr.sbin --- clang: note: diagnostic msg:=20 ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/parser-392d84.c clang: note: diagnostic msg: /tmp/parser-392d84.sh clang: note: diagnostic msg:=20 ******************** *** [parser.o] Error code 254 make[4]: stopped in /usr/src/usr.sbin/nscd 1 error Detailed context: make.conf: empty. src.conf: TO_TYPE=3Darmv6 # KERNCONF=3DRPI2-NODBG TARGET=3Darm .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BINTOOLS_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_LLDB=3D WITH_CLANG_EXTRAS=3D WITH_BOOT=3D # WITHOUT_LIB32=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG=3D WITH_DEBUG_FILES=3D # .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/bin/clang -v -target ${TO_TYPE}--freebsd11.0-gnueabi -march=3Dar= mv7a -mcpu=3Dcortex-a7 -mno-unaligned-access XCXX=3D/usr/bin/clang++ -v -target ${TO_TYPE}--freebsd11.0-gnueabi -march= =3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access XCPP=3D/usr/bin/clang-cpp -v -target ${TO_TYPE}--freebsd11.0-gnueabi -march=3Darmv7a -mcpu=3Dcortex-a7 -mno-unaligned-access .export XCC .export XCXX .export XCPP .endif # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang -v CXX=3D/usr/bin/clang++ -v CPP=3D/usr/bin/clang-cpp -v .export CC .export CXX .export CPP .endif RPI2-NODBG: ident RPI2-NODBG include "RPI2" makeoptions DEBUG=3D-g # Build kernel with gdb(1) debug symbols options ALT_BREAK_TO_DEBUGGER #options VERBOSE_SYSINIT # Enable verbose sysinit messages options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic options DDB # Enable the kernel debugger nooptions INVARIANTS # Enable calls of extra sanity chec= king nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks= and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed nooptions DIAGNOSTIC --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Jan 16 07:52:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDFBFA832F2 for ; Sat, 16 Jan 2016 07:52:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 758AF1A17 for ; Sat, 16 Jan 2016 07:52:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1aKLf8-000F9I-2P; Sat, 16 Jan 2016 09:52:42 +0200 Received: from [132.65.179.20] (helo=mbpro2.bs.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1aKLf7-0000dI-UH; Sat, 16 Jan 2016 09:52:42 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: cross compiling for rpi2 From: Daniel Braniss In-Reply-To: Date: Sat, 16 Jan 2016 09:52:45 +0200 Cc: freebsd-arm Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 07:52:58 -0000 > On 15 Jan 2016, at 9:39 PM, Warner Losh wrote: >=20 > I didn't get those when I built head last night. Nor when I built this = morning. >=20 > Warner >=20 I was missing=20 device generic_timer in my kernel conf file. thanks, danny > On Fri, Jan 15, 2016 at 1:13 AM, Daniel Braniss > wrote: > Hi, > with the latest current I=E2=80=99m getting: > =E2=80=A6 > linking kernel.full > cam_periph.o: In function `cam_periph_alloc': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:258: undefined reference to = `DELAY' > /r+d/vanilla/11/src/sys/cam/cam_periph.c:271: undefined reference to = `DELAY' > cam_periph.o: In function `camperiphfree': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:680: undefined reference to = `DELAY' > cam_periph.o: In function `cam_periph_invalidate': > /r+d/vanilla/11/src/sys/cam/cam_periph.c:610: undefined reference to = `DELAY' > cam_xpt.o: In function `xpt_run_devq': > /r+d/vanilla/11/src/sys/cam/cam_xpt.c:3294: undefined reference to = `DELAY' > cam_xpt.o:/r+d/vanilla/11/src/sys/cam/cam_xpt.c:3035: more undefined = references to `DELAY' follow > *** Error code 1 >=20 > is there a quick fix? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " >=20 From owner-freebsd-arm@freebsd.org Sat Jan 16 10:26:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A904A83ECE for ; Sat, 16 Jan 2016 10:26:41 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 990311305 for ; Sat, 16 Jan 2016 10:26:40 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id u188so50601413wmu.1 for ; Sat, 16 Jan 2016 02:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=bkJG2c60HRP3BJHVrmCgCRa6CaWS49Wz2akM2cPSmAc=; b=AS9CXoBxBInDngnHX/LvTqVhf0lzh0/ozdWgwcC2XUsqr0Qd9xlZve1aRiFBRmFoqO /7iM6dKd0bdej27IYiuo1gKBgHJ80hXpkWhZ/gXDG9h417Y1vg+16q3FjHMOJKRY82Dz JWtGs4Mk+TeVvqLmAfcFz19CzZimQSvw0V34ypRIjkWasgrfymcANbLSDmScNDPpXyD+ P9EvQBbwhVWRi4tYOSOxDIaKuupUVVw3j0PGjVi1Lwaq8nIGwL8MMu7KFtH6X86Ay2Cd 9mWaIf/JSd3gn37MvD3RVM7FNON54xvPcoNRxqmBh8x0aSUtEZ1hCY1la3jHcuI6230H +oEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=bkJG2c60HRP3BJHVrmCgCRa6CaWS49Wz2akM2cPSmAc=; b=g18BNfKHpC38NeiNQkuNFGZTkDdde9MgZlVwLjc4fHw99efLM+DRcjt9vs+Fs6fSMg qy47g+z/FSLJ81/toBymOfud6YuUtiYchDdxC/Z7TUN28XOGNZFnPIIEhTCtMHhmEvkR pbWFaNMgKwGlc+b0oAdOcJ0iQqIYctH7gz5frCA+WTvxJdre9x2PDfDUP5GktytfZS2G G6lFFo/zAuRVDG46czQN0L7jS2aTKhz/9Zn8Y64RNi/EFBEX9qqWncZ6+wJY2eCYB1Ah satpal4KnhMyh5lMjw5V6XCKGg1R6rEDIjkIjUnoj9dofuPgDDp61qIFna/5vGn8IzVJ hKMw== X-Gm-Message-State: ALoCoQnQSzOKt1DS3VJ0uwW0Eo47esx7DZ8QxUy6wy/yez+Bkt+FRqr0vjrTDkIFZwdpkHk6UW51r+0Bu/m3TSMukmNBx/hgiQ== X-Received: by 10.194.82.229 with SMTP id l5mr16536552wjy.140.1452939999178; Sat, 16 Jan 2016 02:26:39 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id g187sm6320612wmf.8.2016.01.16.02.26.38 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 02:26:38 -0800 (PST) To: freebsd-arm From: Jukka Ukkonen Subject: Something odd going on with WITHOUT_DEBUG_FILES X-Enigmail-Draft-Status: N1110 Message-ID: <569A1ADD.5000301@gmail.com> Date: Sat, 16 Jan 2016 12:26:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 10:26:41 -0000 Hello all, When I build head/current using WITHOUT_DEBUG_FILES="yes" the install phase falls on its face with the following notes... install -T debug -o root -g wheel -m 444 libc.so.7.debug /tank/fish/jau/Xcomp/mnt/usr/lib/debug/lib/ install: libc.so.7.debug: No such file or directory I take this means "make installworld" blindly assumes the .debug file should be there, though, it has not been built at all. Oh yes... The cross build host was an amd64 running a fresh 10-stable and the target environment was 11-current on RPI2. --jau From owner-freebsd-arm@freebsd.org Sat Jan 16 10:29:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A39F3A83FD5 for ; Sat, 16 Jan 2016 10:29:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 6F50D13AD for ; Sat, 16 Jan 2016 10:29:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A1D941FE024; Sat, 16 Jan 2016 11:29:07 +0100 (CET) Subject: Re: Something odd going on with WITHOUT_DEBUG_FILES To: Jukka Ukkonen , freebsd-arm References: <569A1ADD.5000301@gmail.com> From: Hans Petter Selasky Message-ID: <569A1BF9.3040106@selasky.org> Date: Sat, 16 Jan 2016 11:31:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <569A1ADD.5000301@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 10:29:16 -0000 On 01/16/16 11:26, Jukka Ukkonen wrote: > > Hello all, > > When I build head/current using WITHOUT_DEBUG_FILES="yes" the install > phase falls on its face with the following notes... > > install -T debug -o root -g wheel -m 444 libc.so.7.debug > /tank/fish/jau/Xcomp/mnt/usr/lib/debug/lib/ > install: libc.so.7.debug: No such file or directory > > I take this means "make installworld" blindly assumes the .debug file > should be there, though, it has not been built at all. > > Oh yes... The cross build host was an amd64 running a fresh 10-stable > and the target environment was 11-current on RPI2. > Hi, Maybe you need to run: make distrib-dirs DESTDIR=/tank/fish/jau/Xcomp/mnt First, to create the missing directories. --HPS From owner-freebsd-arm@freebsd.org Sat Jan 16 16:28:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAC66A836C2 for ; Sat, 16 Jan 2016 16:28:45 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 6AB3D19B5 for ; Sat, 16 Jan 2016 16:28:45 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id u0GGSe9T037814 for ; Sat, 16 Jan 2016 17:28:41 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Sat, 16 Jan 2016 17:28:40 +0100 (CET) Message-ID: <478e3ea07e5.2d0fbb8b@mail.schwarzes.net> In-Reply-To: <569A1ADD.5000301@gmail.com> References: <569A1ADD.5000301@gmail.com> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Something odd going on with WITHOUT_DEBUG_FILES MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Sat, 16 Jan 2016 17:28:42 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 16:28:45 -0000 On 16.01.16, Jukka Ukkonen wrote: Hi Jukka, > install -T debug -o root -g wheel -m 444 libc.so.7.debug > /tank/fish/jau/Xcomp/mnt/usr/lib/debug/lib/ > install: libc.so.7.debug: No such file or directory > > I take this means "make installworld" blindly assumes the .debug file > should be there, though, it has not been built at all. You have called the "make installworld" with the WITHOUT_DEBUG_FILES option too? -asc From owner-freebsd-arm@freebsd.org Sat Jan 16 20:38:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E63FA85BF2 for ; Sat, 16 Jan 2016 20:38:46 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1F011DF4 for ; Sat, 16 Jan 2016 20:38:45 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id c192so300624289lfe.2 for ; Sat, 16 Jan 2016 12:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0kROOWTyaAW8J34PNSbEav6AWRI8ZwJ8Rkpi9Ll9LxQ=; b=pSZQweTZzCFNcr9bD9N3dkMpwBoBUDfOTBUFK5UBTUXK1CqGwvnz+/gCJHifMP7nOd Xrrw3d6VczF9Ao2rmUFQ7V91k+zxhBftne31rVq4hGsmVctVRb55F7J9On9bgAi8HgHt EvAkLZhB1q+UxkLpi0ySHqvln5aY3J0scobmlyiJ14GZyQ/iMhoVV9GEHsWCpEUfVkrn l5XBxnlakNM/tm5mVjVcuTQCy4TgJSx/92AriAqNcVf9Ystas9UJRsD7ir6lS7Betohp Jrvpt88fYQVbHdzpdIEfdJ1sbF0NLR7SelTZDPMUicuXZQxp6DTkKFBZDtZrtoydgv5m ksJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0kROOWTyaAW8J34PNSbEav6AWRI8ZwJ8Rkpi9Ll9LxQ=; b=Z4hEL/UymoK6tu/U4opytJHtplHpAeQvLsTX3kaMw4ZmdIpd9zhj1h8Ga25LQJzfFS Siyi9uCUC+XMVlIrVt8y1+Gxyt/uSgWeXiCMvirU0AXwV1qiWVfgZSU6HbgVa4zzB0KJ qSzWIpYG5y7mZjRIl482tEgeMJ0hTMn1q3Oc8QCORYn0HWZLge8CDFwwVCZJrjVnMQZC XNsCrgsRA/m3Fz6x/9lAh87wkxDqlhNH5zSqmKKGO7IjOSi6vvbUXAu8qx0O43hads1U 17eZWacLuyRmDUroJB6bIeJoGYhKb8tm0Yn86Pw3Iggw7UX10XZQuqwA3CpfwTIG2Q5r kbrQ== X-Gm-Message-State: ALoCoQle/cmppurhW2mUildqRCo6Z4DO2YEb8KmrXlVVZG9MEm1ipLeCHNDda+1diufphgvbUPSBrn7+jBI51dJCoLo4znfh0g== X-Received: by 10.25.158.136 with SMTP id h130mr5590474lfe.136.1452976723923; Sat, 16 Jan 2016 12:38:43 -0800 (PST) Received: from [192.168.1.193] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.gmail.com with ESMTPSA id ak1sm2039763lbc.2.2016.01.16.12.38.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 12:38:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Something odd going on with WITHOUT_DEBUG_FILES From: Jukka Ukkonen X-Mailer: iPad Mail (13C75) In-Reply-To: <478e3ea07e5.2d0fbb8b@mail.schwarzes.net> Date: Sat, 16 Jan 2016 22:38:38 +0200 Cc: freebsd-arm@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: References: <569A1ADD.5000301@gmail.com> <478e3ea07e5.2d0fbb8b@mail.schwarzes.net> To: Andreas Schwarz X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 20:38:46 -0000 > On 16 Jan 2016, at 18:28, Andreas Schwarz wrote: > > On 16.01.16, Jukka Ukkonen wrote: > > Hi Jukka, > >> install -T debug -o root -g wheel -m 444 libc.so.7.debug >> /tank/fish/jau/Xcomp/mnt/usr/lib/debug/lib/ >> install: libc.so.7.debug: No such file or directory >> >> I take this means "make installworld" blindly assumes the .debug file >> should be there, though, it has not been built at all. > > You have called the "make installworld" with the WITHOUT_DEBUG_FILES > option too? Actually I set it in src.conf. Should I take that as an indication that installworld does not include src.conf? --jau From owner-freebsd-arm@freebsd.org Sat Jan 16 21:10:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1037A846B9 for ; Sat, 16 Jan 2016 21:10:06 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 60D761AB4 for ; Sat, 16 Jan 2016 21:10:06 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.15.2/8.15.2) with ESMTPA id u0GLA1Nx038658; Sat, 16 Jan 2016 22:10:02 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Jukka Ukkonen CC: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Sat, 16 Jan 2016 22:10:00 +0100 (CET) Message-ID: <478e80b829.3480d793@mail.schwarzes.net> In-Reply-To: References: <569A1ADD.5000301@gmail.com> <478e3ea07e5.2d0fbb8b@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Something odd going on with WITHOUT_DEBUG_FILES MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Sat, 16 Jan 2016 22:10:03 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 21:10:06 -0000 On 16.01.16, Jukka Ukkonen wrote: >> On 16 Jan 2016, at 18:28, Andreas Schwarz wrote: >> You have called the "make installworld" with the WITHOUT_DEBUG_FILES >> option too? > > Actually I set it in src.conf. > Should I take that as an indication that installworld > does not include src.conf? Ah ok, thought that you are adding the option when calling the make command. The src.conf is the right place. When building directy at the rpi2 the option will be respected. For crossbuilding I've no idea how this is handled. -asc