From owner-freebsd-toolchain@freebsd.org Mon Dec 28 11:33:13 2015 Return-Path: Delivered-To: freebsd-toolchain@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 46EDAA545EB for ; Mon, 28 Dec 2015 11:33:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-151.reflexion.net [208.70.211.151]) (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 F16EC19D2 for ; Mon, 28 Dec 2015 11:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5729 invoked from network); 28 Dec 2015 11:33:17 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 11:33:17 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 28 Dec 2015 06:33:09 -0500 (EST) Received: (qmail 27301 invoked from network); 28 Dec 2015 11:33:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Dec 2015 11:33: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 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 E784D1C43A0; Mon, 28 Dec 2015 03:33:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error? From: Mark Millard In-Reply-To: <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> Date: Mon, 28 Dec 2015 03:33:09 -0800 Cc: freebsd-arm , FreeBSD Toolchain , Ian Lepore , mat@FreeBSD.org, sbruno@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <0D81C2CA-BF1C-4C14-B816-A8C5F68715B5@bsdimp.com> <51EB4AAB-BC81-4282-BA4D-D329C41D660B@dsl-only.net> <8B52074F-FDEF-4119-BB04-630F9BE9E6DB@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Mon, 28 Dec 2015 12:35:38 +0000 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2015 11:33:13 -0000 [I have both dropped a bunch of older history and started a new break.] The clang++ Bus Errors are a compiler implementation defect(!), as shown = below. (Presumes they want clang++ to work in contexts where alignment = is required.) In summary: The clang++ source code presumes that there are no alignment criteria to = be met for TemplateArgument instances from the "arg buffer" for any = DependentTemplateSpecializationType instance. The details. . . I finally have a 11-line example source file (no includes) that crashes = clang++ on the rpi2. (The example is a partial item from libc++'s = .) > # more main.cc > template > struct __has_rebind > { > template static char __test(typename _Xp::template = rebind<_Up>* =3D 0); > }; >=20 > int > main () > { > return 0; > } The backtrace in clang++ looks like: > Program terminated with signal 10, Bus error. > #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () > [New Thread 22a18000 (LWP 100182/)] > (gdb) bt > #0 0x00c404d0 in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () > #1 0x00d86634 in = clang::ASTContext::getDependentTemplateSpecializationType () > #2 0x00d865d8 in = clang::ASTContext::getDependentTemplateSpecializationType () > #3 0x00d862d4 in = clang::ASTContext::getDependentTemplateSpecializationType () > #4 0x00553b7c in clang::Sema::ActOnTypenameType () > #5 0x0040cb68 in clang::Parser::TryAnnotateTypeOrScopeToken () > #6 0x00471198 in $a.28 () > #7 0x00471198 in $a.28 () > (gdb) x/1i 0x00c404d0 > 0xc404d0 = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>:=09 > vst1.64 {d16-d17}, [r4]! > (gdb) info all-registers > r0 0xbfbf9778 -1077962888 > r1 0x22ac59c4 581720516 > r2 0xc45ff8 12869624 > r3 0x2 2 > r4 0x22ac59ac 581720492 . . . The code involved is from lib/AST/Type.cpp : > = DependentTemplateSpecializationType::DependentTemplateSpecializationType( > ElaboratedTypeKeyword Keyword, > NestedNameSpecifier *NNS, const = IdentifierInfo *Name, > unsigned NumArgs, const TemplateArgument = *Args, > QualType Canon) > : TypeWithKeyword(Keyword, DependentTemplateSpecialization, Canon, = true, true, > /*VariablyModified=3D*/false, > NNS && NNS->containsUnexpandedParameterPack()), > NNS(NNS), Name(Name), NumArgs(NumArgs) { > assert((!NNS || NNS->isDependent()) && > "DependentTemplateSpecializatonType requires dependent = qualifier"); > for (unsigned I =3D 0; I !=3D NumArgs; ++I) { > if (Args[I].containsUnexpandedParameterPack()) > setContainsUnexpandedParameterPack(); > =20 > new (&getArgBuffer()[I]) TemplateArgument(Args[I]); > } > } The failing code is for the "placement new" in the loop: A) &getArgBuffer()[I] is not always an address for which the vst1.64 = instruction gets an aligned address. but. . . B) TemplateArgument(Args[I])'s copy construction activity has code (such = as the vst1.64) requiring a specific alignment when SCTLR bit[1]=3D=3D1. C) Nothing here has any explicitly packed data structures. As for (A): > class DependentTemplateSpecializationType : > public TypeWithKeyword, public llvm::FoldingSetNode { > . . . > const TemplateArgument *getArgBuffer() const { > return reinterpret_cast(this+1); > } > TemplateArgument *getArgBuffer() { > return reinterpret_cast(this+1); > } clang++ is over-allocating the space for the = DependentTemplateSpecializationType objects and using the extra space = that is afterwards to hold (a somewhat C-style array of) = TemplateArgument instances. But the logic for this does nothing explicit = about alignment of the TemplateArgument instance pointers, not even = partially via explicitly controlling = sizeof(DependentTemplateSpecializationType). This code does not explicitly force any specific minimum = TemplateArgument alignment, other than 1. Separately there is the issue that the code produced did not treat the = pointers returned from getArgBuffer() methods as "opaque pointer" = examples but they are. Having compiled with -fmax-type-align=3D4 the = code should have not have required 8 byte alignment (vst1.64). It should = have produced code that required 4 (or 2 or 1). Quoting for = -fmax-type-align=3D?: > Instruct the code generator to not enforce a higher alignment than the = given number (of bytes) when accessing memory via an opaque pointer or = reference Those pointers certainly are opaque and should be treated as such. The = "reinterpret_cast" use is a big clue that clang++ should respect. In other words: I see two clang++ defects in the overall evidence, one = of which directly leads to the Bus Errors being possible. The script of the buildworld/buildkernel shows that -fmax-type-align=3D4 = -mno-unaligned-access were both used to compile the Type.cpp source = file: > --- Type.o --- > /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -target = armv6-gnueabi-freebsd11.0 --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp= -B/usr/local > /arm-gnueabi-freebsd/bin/ = --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp = -B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/inclu > de = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include= = -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST= -I. -I/usr/src/lib/clang/libclangast/../../../c > ontrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD = -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFA > ULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.Type.o -MTType.o = -Qunused-arguments -std=3Dc++11 -fno-exceptio > ns -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/T= ype.cpp -o Type.o clang++ may well have other examples of such things in other classes. I = have not looked. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Dec-28, at 12:01 AM, Mark Millard wrote: >=20 >=20 > On 2015-Dec-26, at 8:45 AM, Warner Losh wrote: >=20 >> Thanks, it sounds like I fixed a bug, but there=E2=80=99s more. >>=20 >> What were the specific port so I can test it here? >>=20 >> And to be clear, this is a buildworld on the RPi 2 using the = cross-built world with CPUTYPE=3Darmv7a or some such, right? >>=20 >> Warner >>=20 >>> On Dec 25, 2015, at 9:32 PM, Mark Millard = wrote: >>>=20 >>> [I am again breaking off another section of older material.] >>>=20 >>> Mixed news I'm afraid. >>>=20 >>> The specific couple of ports that I attempted did build, the same = ones that originally got the Bus Error in ar using (indirectly) _fseeko = and memset that I reported. So I expect that you fixed one error. >>>=20 >>> But when I tried to buildworld, clang++ 3.7 processing = usr/src/lib/clang/libllvmtablegen/ materials quickly got a Bus Error at = nearly the same type of instruction (it has a "!" below that the earlier = one did not), but with r4 holding the misaligned address this time: >>>=20 >>>> --- _bootstrap-tools-lib/clang/libllvmsupport --- >>>> --- APFloat.o --- >>>> clang++: error: unable to execute command: Bus error (core dumped) >>>> . . . >>>> # gdb clang++ usr/src/lib/clang/libllvmtablegen/clang++.core >>>> . . . >>>> Core was generated by `clang++'. >>>> Program terminated with signal 10, Bus error. >>>> #0 0x00c3bb9c in = clang::DependentTemplateSpecializationType::DependentTemplateSpecializatio= nType () >>>> [New Thread 22a18000 (LWP 100128/)] >>>> (gdb) x/40i 0x00c3bb60 >>>> . . . >>>> 0xc3bb9c = <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywo= rdEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumen= tENS_8QualTypeE+356>: >>>> vst1.64 {d16-d17}, [r4]! >>>> . . . >>>> (gdb) info all-registers >>>> r0 0xbfbf81a8 -1077968472 >>>> r1 0x22f07e14 586186260 >>>> r2 0xc416bc 12850876 >>>> r3 0x2 2 >>>> r4 0x22f07dfc 586186236 >>>> . . . >>>=20 >>>=20 >>> Thus it appears that there is more code around that likely generates = pointers not aligned so to allow the code generation that is in use for = what is pointed to. >>>=20 >>> At this point I have no clue if the issue is just inside clang = itself vs. if it is in something that clang is layered on top of. Nor if = there is just one bad thing or many. >>>=20 >>> Note: I had not yet tried buildworld/buildkernel for the context of = the "-f" option that I was experimenting with earlier. So I do not have = a direct compare and contrast at this point. >=20 > Somehow I did not notice your E-mail at the time. Meanwhile I've more = evidence. . . >=20 > [Initial context for notes: Before updating to 11.0-CURRENT -r292756 = and its clang/clang++ 3.7.1.] >=20 > Example c++ program that clang++ got an internal Bus Error for: >=20 >> # more main.cc >> #include >> int >> main () >> { >> std::ostream *o; return 0; >> } >=20 > Of course the include makes the source being processed non-trivial. >=20 > Going in a different direction. . . dmesg -a | grep "core dumped" on = the rpi2 showed: >=20 >> pid 22238 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 22250 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 22259 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 26149 (msgfmt), uid 0: exited on signal 11 (core dumped) >> pid 26161 (xgettext), uid 0: exited on signal 11 (core dumped) >> pid 26170 (msgmerge), uid 0: exited on signal 11 (core dumped) >> pid 28826 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29202 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29282 (c++), uid 0: exited on signal 10 (core dumped) >> pid 29292 (clang++), uid 0: exited on signal 10 (core dumped) >=20 > Only the c++/clang++ contexts (same but for name) seemed to be leaving = .core files behind. >=20 > The older log files also showed examples like the following from ports = building activity: >=20 >> /var/log/dmesg.today:pid 18763 (conftest), uid 0: exited on signal 11 = (core dumped) >> /var/log/dmesg.today:pid 18916 (conftest), uid 0: exited on signal 11 = (core dumped) >=20 > (The original ar that I started with showed as well, the records went = back that far at the time.) >=20 > [New -r292756 context. . .] >=20 > After the above I updated to: >=20 >> $ freebsd-version -ku; uname -aKU >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r292756M: Sun Dec = 27 02:55:57 PST 2015 = root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm = 1100092 1100092 >=20 > in order to pick up clang 3.7.1. I used -fmax-type-align=3D4 = -mno-unaligned-access in the src.conf file for the buildworld = buildkernel amd64->rpi2 cross build before installing both parts on the = rpi2 media. >=20 > On the rpi2 itself the resulting c++/clang++ still gets Bus Error = during buildworld despite the use of -fmax-type-align=3D4 = -mno-unaligned-acces in the amd64 hosted cross build (and in the rpi2 = attempted rebuild). An example crash report is: >=20 >> /usr/bin/clang++ -B/usr/local/arm-gnueabi-freebsd/bin -march=3Darmv7a = -fmax-type-align=3D4 -mno-unaligned-access -O -pipe -mfloat-abi=3Dsoftfp = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"armv6-gnueabi-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.APFloat.o -MTAPFloat.o = -Qunused-arguments = -I/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/include -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp -o APFloat.o >> clang++: error: unable to execute command: Bus error (core dumped) >> clang++: error: clang frontend command failed due to signal (use -v = to see invocation) >> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 >> Target: armv6--freebsd11.0-gnueabi >> Thread model: posix >> clang++: note: diagnostic msg: PLEASE submit a bug report to = https://bugs.freebsd.org/submit/ and include the crash backtrace, = preprocessed source, and associated run script. >> 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/APFloat-04544c.cpp >> clang++: note: diagnostic msg: /tmp/APFloat-04544c.sh >> clang++: note: diagnostic msg:=20 >>=20 >> ******************** >> *** Error code 254 >>=20 >> Stop. >> make[3]: stopped in /usr/src/lib/clang/libllvmsupport >> *** Error code 1 >=20 > An earlier -j 6 buildworld had failures for ARMBuildAttrs, APSInt, = APInt, and Error before stopping, in addition to the APFloat indicated = above (no -j makes for easier reading above): >=20 >> # ls -lt /tmp >> total 41516 >> -rw-r--r-- 1 root wheel 4057 Dec 28 03:05 APFloat-04544c.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 03:05 APFloat-04544c.cpp >> -rw-r--r-- 1 root wheel 4081 Dec 28 02:53 = ARMBuildAttrs-432569.sh >> -rw-r--r-- 1 root wheel 1276912 Dec 28 02:53 = ARMBuildAttrs-432569.cpp >> -rw-r--r-- 1 root wheel 3997 Dec 28 02:53 APSInt-a2927e.sh >> -rw-r--r-- 1 root wheel 1943445 Dec 28 02:53 APSInt-a2927e.cpp >> -rw-r--r-- 1 root wheel 3985 Dec 28 02:53 APInt-d0389a.sh >> -rw-r--r-- 1 root wheel 2115595 Dec 28 02:53 APInt-d0389a.cpp >> -rw-r--r-- 1 root wheel 4009 Dec 28 02:53 APFloat-33be1b.sh >> -rw-r--r-- 1 root wheel 2155452 Dec 28 02:53 APFloat-33be1b.cpp >> -rw-r--r-- 1 root wheel 4001 Dec 28 02:53 Error-777068.sh >> -rw-r--r-- 1 root wheel 1925065 Dec 28 02:53 Error-777068.cpp >=20 > The earlier "iostream" program example also still gets its Bus Error = during its clang++ based compilation in this new -r292756 context. >=20 > The above -r292756 material avoids involving ports software with its = own set of additional questions, compilers, tools, etc.: it sticks to = buildworld/buildkernel material (and never gets to buildkernel). >=20 > When I tried -j 5 buildkernel by itself on the rpi2 there were no Bus = Errors, no Segmentation Faults, and no core dumps. The buildkernel took = about 51 minutes. (I've not tried installing what it built.) >=20 > (I have a SSD on a USB hub in use for world/root on the rpi2. The = /etc/fstab on the micro-SD lists / as mounting from the SSD instead. I = installkernel and installworld via the amd64 context to both the = micro-SD and the SSD so that they track. I can boot from just the = micro-SD if I want to but normally involve the SSD.) >=20 > Another kind of experiment would be to omit -fmax-type-align=3D4 but = use -mno-unaligned-access (for handling any packed data structures) and = see if buildkernel can still finish on the rpi2 (if enough of the = amd64->rpi2 buildworld still operates on the rpi2 to allow the test). >=20 > A potential experiment for buildworld would be to use = -fmax-type-align=3D1 with -mno-unaligned-access as the amd64->rpi2 cross = build context. A misalignment Bus Error from that context might well be = a clang++ code generation error of not paying attention to the alignment = rules where clang++ should. >=20 > A potentially interesting (but independent) set of warnings during the = buildkernel was: >=20 >> WARNING: hwpmc_mod.c: enum pmc_event has too many values: 2588 > 1023 >> WARNING: hwpmc_logging.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_soft.c: enum pmc_event has too many values: 2588 > = 1023 >> WARNING: hwpmc_arm.c: enum pmc_event has too many values: 2588 > 1023 >=20 > (I've not investigated.) >=20 >=20 >=20 > Before this -r292756 update the following ports seemed to have built = without generating core dumps or Bus Error reports or other such in the = process: >=20 > devel/gettext-tools > devel/gmake-lite > devel/p5-Locale-gettext > lang/perl5.22 > security/sudo >=20 > Note that I did not use make.conf to force -f. . . and -m. . . for = these. But the test was if they could build, not if they operated = correctly when built. >=20 > My guess is that they are primarily C instead of C++ and/or happen to = avoid the parts of C++ where clang++ is having internal data structure = alignment problems vs. SCTLR bit[1]=3D=3D1. >=20 > Generally the pkg installs on the rpi2 seemed to have been operating = okay. But they do nto test compiling/linking with the system = clang/clang++ involved. >=20 > In general building ports can have other issues that block completion = so I had not tried much in that direction and happened to pick on a few = things that worked (see above). Getting through a self-hosting rpi2 = buildworld buildkernel first likely is a better path before involving = ports. >=20 > But my way of working has involved using devel/arm-gnueabi-binutils , = which seemed to build and work fine. >=20 >=20 > One thing of note from all my rpi2 builds: I've learned to avoid doing = a "svnlite status /usr/src/" and similar commands. Fairly frequently = they do not complete and each existing ssh connection to the rpi2 quits = responding once some new program is attempted from the connection. The = same for directly at the rpi2 (via USB devices). >=20 > Unfortunately /var/log/messages only shows the following boot, no = messages from the hang-up context. I'd guess that USB (and other such?) = communication stopped operating. >=20 >=20 >=20 > The src.conf for on the rpi2 has (the amd64->rpi2 cross compile was = very similar but the amd64-host-targets-self clang/clang++ commands do = not need the -f. . . and -m. . . ): >=20 >> TO_TYPE=3Darmv6 >> TOOLS_TO_TYPE=3Darm-gnueabi >> FROM_TYPE=3D${TO_TYPE} >> TOOLS_FROM_TYPE=3D${TOOLS_TO_TYPE} >> VERSION_CONTEXT=3D11.0 >> # >> KERNCONF=3DRPI2-NODBG >> TARGET=3Darm >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER=3D >> # >> # For WITH_BOOT=3D . . . (amd64 cross compile context) >> # arm-gnueabi-freebsd/bin/ld reports bootinfo.o: relocation = R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a = shared object; recompile with -fPIC=20 >> WITHOUT_BOOT=3D >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >> WITH_CLANG_EXTRAS=3D >> # >> WITHOUT_LIB32=3D >> WITHOUT_GCC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> MALLOC_PRODUCTION=3D >> #CFLAGS+=3D -DELF_VERBOSE >> # >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D >> # >> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... >> # >> #CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc >> X_COMPILER_TYPE=3Dclang >> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >> .if ${.MAKE.LEVEL} =3D=3D 0 >> XCC=3D/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCXX=3D/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> XCPP=3D/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export XCC >> .export XCXX >> .export XCPP >> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >> #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings >> .export XAS >> .export XAR >> .export XLD >> .export XNM >> .export XOBJCOPY >> .export XOBJDUMP >> .export XRANLIB >> .export XSIZE >> .export XSTRINGS >> .endif >> # >> # =46rom clang (via system)... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> CC=3D/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CXX=3D/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> CPP=3D/usr/bin/clang-cpp -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin = -march=3Darmv7a -fmax-type-align=3D4 -mno-unaligned-access >> .export CC >> .export CXX >> .export CPP >> .endif >> # >> # >> # TOOLS_FROM_TYPE binutils from xtoolchain like context... >> # >> .if ${.MAKE.LEVEL} =3D=3D 0 >> AS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as >> AR=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar >> LD=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld >> NM=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm >> OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy >> OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump >> RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib >> SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size >> #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings >> STRINGS=3D/usr/local/bin/${TOOLS_FROM_TYPE}-freebsd-strings >> .export AS >> .export AR >> .export LD >> .export NM >> .export OBJCOPY >> .export OBJDUMP >> .export RANLIB >> .export SIZE >> .export STRINGS >> .endif >=20 > This technique does require devel/arm-gnueabi-binutils to have been = built and operating okay on amd64 and later on the rpi2. So far I've no = hints of any problems in that area. >=20 >=20 >=20 > The RPI2-NODBG config is shown below: >=20 >> # more /usr/src/sys/arm/conf/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 > Most of my /usr/src/ tailoring is tied to powerpc and powerpc64 = issues: >=20 >> # svnlite status /usr/src/ >> ? /usr/src/.snap >> M /usr/src/contrib/libcxxrt/guard.cc >> M /usr/src/lib/csu/powerpc64/Makefile >> M /usr/src/lib/libc/stdio/findfp.c >> ? /usr/src/lib/libc/stdio/findfp.c.orig >> ? /usr/src/restoresymtable >> ? /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 >=20 > lib/libc/stdio/findfp.c has the patch I was asked to test. >=20 > contrib/libcxxrt/guard.cc is to avoid bad C++ source code (use of = C11-specific notation in C++ that is reported syntax errors in = powerpc64-xtoolchain-gcc/powerpc64-gcc compilation contexts): >=20 >> # svnlite diff /usr/src/contrib/libcxxrt/guard.cc >> Index: /usr/src/contrib/libcxxrt/guard.cc >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/contrib/libcxxrt/guard.cc (revision 292756) >> +++ /usr/src/contrib/libcxxrt/guard.cc (working copy) >> @@ -101,7 +101,7 @@ >> uint32_t init_half; >> uint32_t lock_half; >> } guard_t; >> -_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> +//_Static_assert(sizeof(guard_t) =3D=3D sizeof(uint64_t), ""); >> static const uint32_t LOCKED =3D 1; >> static const uint32_t INITIALISED =3D static_cast(1) << = 24; >> # endif >=20 > The sys/boot/. . . examples are just use of -Wl, notation in LDFLAGS = where the original notation was rejected, such as: >=20 >> # svnlite diff /usr/src/sys/boot/uboot/Makefile.inc >> Index: /usr/src/sys/boot/uboot/Makefile.inc >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/sys/boot/uboot/Makefile.inc (revision 292756) >> +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) >> @@ -2,7 +2,7 @@ >>=20 >> .if ${MACHINE_ARCH} =3D=3D "powerpc64" >> CFLAGS+=3D -m32 -mcpu=3Dpowerpc >> -LDFLAGS+=3D -m elf32ppc_fbsd >> +LDFLAGS+=3D -Wl,-m -Wl,elf32ppc_fbsd >> .endif >>=20 >> .include "../Makefile.inc" >=20 > All 3 are powerpc64 specific changes. >=20 > =3D=3D=3D Mark Millard markmi at dsl-only.net