On 2015-Dec-28, at 3:33 AM, Mark Millard <mar...@dsl-only.net> wrote:
> [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 <memory>.) > >> # more main.cc >> template <class _Tp, class _Up> >> struct __has_rebind >> { >> template <class _Xp> static char __test(typename _Xp::template >> rebind<_Up>* = 0); >> }; >> >> int >> main () >> { >> return 0; >> } > > The backtrace in clang++ looks like: > >> Program terminated with signal 10, Bus error. >> #0 0x00c404d0 in >> clang::DependentTemplateSpecializationType::DependentTemplateSpecializationType >> () >> [New Thread 22a18000 (LWP 100182/<unknown>)] >> (gdb) bt >> #0 0x00c404d0 in >> clang::DependentTemplateSpecializationType::DependentTemplateSpecializationType >> () >> #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_21ElaboratedTypeKeywordEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumentENS_8QualTypeE+356>: >> >> 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=*/false, >> NNS && NNS->containsUnexpandedParameterPack()), >> NNS(NNS), Name(Name), NumArgs(NumArgs) { >> assert((!NNS || NNS->isDependent()) && >> "DependentTemplateSpecializatonType requires dependent qualifier"); >> for (unsigned I = 0; I != NumArgs; ++I) { >> if (Args[I].containsUnexpandedParameterPack()) >> setContainsUnexpandedParameterPack(); >> >> 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]==1. > > 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<const TemplateArgument*>(this+1); >> } >> TemplateArgument *getArgBuffer() { >> return reinterpret_cast<TemplateArgument*>(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=4 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=?: > >> 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=4 > -mno-unaligned-access were both used to compile the Type.cpp source file: > >> --- Type.o --- >> /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=armv7a >> -fmax-type-align=4 -mno-unaligned-access -target armv6-gnueabi-freebsd11.0 >> --sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp -B/usr/local >> /arm-gnueabi-freebsd/bin/ --sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp >> -B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=softfp >> -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=\"armv6-gnueabi-freebsd11.0\" >> -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD >> -MP -MF.depend.Type.o -MTType.o -Qunused-arguments -std=c++11 -fno-exceptio >> ns -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c >> /usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Type.cpp >> -o Type.o > > clang++ may well have other examples of such things in other classes. I have > not looked. I should have mentioned that sizeof(TemplateArgument) also needs to be controlled in order to have the notation &getArgBuffer()[I] maintain alignment in its results when &getArgBuffer()[0] is well aligned. The earlier material focused on just &getArgBuffer()[0] in how it was presented. === Mark Millard markmi at dsl-only.net On 2015-Dec-28, at 12:01 AM, Mark Millard <mar...@dsl-only.net> wrote: > > > On 2015-Dec-26, at 8:45 AM, Warner Losh <i...@bsdimp.com> wrote: > >> Thanks, it sounds like I fixed a bug, but there’s more. >> >> What were the specific port so I can test it here? >> >> And to be clear, this is a buildworld on the RPi 2 using the cross-built >> world with CPUTYPE=armv7a or some such, right? >> >> Warner >> >>> On Dec 25, 2015, at 9:32 PM, Mark Millard <mar...@dsl-only.net> wrote: >>> >>> [I am again breaking off another section of older material.] >>> >>> Mixed news I'm afraid. >>> >>> 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. >>> >>> 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: >>> >>>> --- _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::DependentTemplateSpecializationType >>>> () >>>> [New Thread 22a18000 (LWP 100128/<unknown>)] >>>> (gdb) x/40i 0x00c3bb60 >>>> . . . >>>> 0xc3bb9c >>>> <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywordEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumentENS_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 >>>> . . . >>> >>> >>> 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. >>> >>> 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. >>> >>> 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. > > Somehow I did not notice your E-mail at the time. Meanwhile I've more > evidence. . . > > [Initial context for notes: Before updating to 11.0-CURRENT -r292756 and its > clang/clang++ 3.7.1.] > > Example c++ program that clang++ got an internal Bus Error for: > >> # more main.cc >> #include <iostream> >> int >> main () >> { >> std::ostream *o; return 0; >> } > > Of course the include makes the source being processed non-trivial. > > Going in a different direction. . . dmesg -a | grep "core dumped" on the rpi2 > showed: > >> 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) > > Only the c++/clang++ contexts (same but for name) seemed to be leaving .core > files behind. > > The older log files also showed examples like the following from ports > building activity: > >> /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) > > (The original ar that I started with showed as well, the records went back > that far at the time.) > > [New -r292756 context. . .] > > After the above I updated to: > >> $ 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 > > in order to pick up clang 3.7.1. I used -fmax-type-align=4 > -mno-unaligned-access in the src.conf file for the buildworld buildkernel > amd64->rpi2 cross build before installing both parts on the rpi2 media. > > On the rpi2 itself the resulting c++/clang++ still gets Bus Error during > buildworld despite the use of -fmax-type-align=4 -mno-unaligned-acces in the > amd64 hosted cross build (and in the rpi2 attempted rebuild). An example > crash report is: > >> /usr/bin/clang++ -B/usr/local/arm-gnueabi-freebsd/bin -march=armv7a >> -fmax-type-align=4 -mno-unaligned-access -O -pipe -mfloat-abi=softfp >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include >> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include >> -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=\"armv6-gnueabi-freebsd11.0\" >> -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD >> -MP -MF.depend.APFloat.o -MTAPFloat.o -Qunused-arguments >> -I/usr/obj/clang/arm.armv6/usr/src/tmp/legacy/usr/include -std=c++11 >> -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.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: >> ******************** >> >> 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: >> >> ******************** >> *** Error code 254 >> >> Stop. >> make[3]: stopped in /usr/src/lib/clang/libllvmsupport >> *** Error code 1 > > 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): > >> # 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 > > The earlier "iostream" program example also still gets its Bus Error during > its clang++ based compilation in this new -r292756 context. > > 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). > > 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.) > > (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.) > > Another kind of experiment would be to omit -fmax-type-align=4 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). > > A potential experiment for buildworld would be to use -fmax-type-align=1 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. > > A potentially interesting (but independent) set of warnings during the > buildkernel was: > >> 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 > > (I've not investigated.) > > > > 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: > > devel/gettext-tools > devel/gmake-lite > devel/p5-Locale-gettext > lang/perl5.22 > security/sudo > > 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. > > 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]==1. > > 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. > > 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. > > But my way of working has involved using devel/arm-gnueabi-binutils , which > seemed to build and work fine. > > > 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). > > 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. > > > > 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. . . ): > >> TO_TYPE=armv6 >> TOOLS_TO_TYPE=arm-gnueabi >> FROM_TYPE=${TO_TYPE} >> TOOLS_FROM_TYPE=${TOOLS_TO_TYPE} >> VERSION_CONTEXT=11.0 >> # >> KERNCONF=RPI2-NODBG >> TARGET=arm >> .if ${.MAKE.LEVEL} == 0 >> TARGET_ARCH=${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITHOUT_CROSS_COMPILER= >> # >> # For WITH_BOOT= . . . (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 >> WITHOUT_BOOT= >> # >> WITH_FAST_DEPEND= >> WITH_LIBCPLUSPLUS= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_LLDB= >> WITH_CLANG_EXTRAS= >> # >> WITHOUT_LIB32= >> WITHOUT_GCC= >> WITHOUT_GNUCXX= >> # >> NO_WERROR= >> MALLOC_PRODUCTION= >> #CFLAGS+= -DELF_VERBOSE >> # >> WITH_DEBUG= >> WITH_DEBUG_FILES= >> # >> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils... >> # >> #CROSS_TOOLCHAIN=${TO_TYPE}-gcc >> X_COMPILER_TYPE=clang >> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ >> .if ${.MAKE.LEVEL} == 0 >> XCC=/usr/bin/clang -target ${TO_TYPE}--freebsd11.0-gnueabi -march=armv7a >> -fmax-type-align=4 -mno-unaligned-access >> XCXX=/usr/bin/clang++ -target ${TO_TYPE}--freebsd11.0-gnueabi -march=armv7a >> -fmax-type-align=4 -mno-unaligned-access >> XCPP=/usr/bin/clang-cpp -target ${TO_TYPE}--freebsd11.0-gnueabi >> -march=armv7a -fmax-type-align=4 -mno-unaligned-access >> .export XCC >> .export XCXX >> .export XCPP >> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size >> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >> XSTRINGS=/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 >> # >> # From clang (via system)... >> # >> .if ${.MAKE.LEVEL} == 0 >> CC=/usr/bin/clang -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin -march=armv7a >> -fmax-type-align=4 -mno-unaligned-access >> CXX=/usr/bin/clang++ -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin >> -march=armv7a -fmax-type-align=4 -mno-unaligned-access >> CPP=/usr/bin/clang-cpp -B/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin >> -march=armv7a -fmax-type-align=4 -mno-unaligned-access >> .export CC >> .export CXX >> .export CPP >> .endif >> # >> # >> # TOOLS_FROM_TYPE binutils from xtoolchain like context... >> # >> .if ${.MAKE.LEVEL} == 0 >> AS=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/as >> AR=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ar >> LD=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ld >> NM=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/nm >> OBJCOPY=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objcopy >> OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/objdump >> RANLIB=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/ranlib >> SIZE=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/size >> #NO-SUCH: STRINGS=/usr/local/${TOOLS_FROM_TYPE}-freebsd/bin/strings >> STRINGS=/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 > > 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. > > > > The RPI2-NODBG config is shown below: > >> # more /usr/src/sys/arm/conf/RPI2-NODBG >> ident RPI2-NODBG >> >> include "RPI2" >> >> makeoptions DEBUG=-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 >> 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 > > > Most of my /usr/src/ tailoring is tied to powerpc and powerpc64 issues: > >> # 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 > > lib/libc/stdio/findfp.c has the patch I was asked to test. > > 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): > >> # svnlite diff /usr/src/contrib/libcxxrt/guard.cc >> Index: /usr/src/contrib/libcxxrt/guard.cc >> =================================================================== >> --- /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) == sizeof(uint64_t), ""); >> +//_Static_assert(sizeof(guard_t) == sizeof(uint64_t), ""); >> static const uint32_t LOCKED = 1; >> static const uint32_t INITIALISED = static_cast<guard_lock_t>(1) << 24; >> # endif > > The sys/boot/. . . examples are just use of -Wl, notation in LDFLAGS where > the original notation was rejected, such as: > >> # svnlite diff /usr/src/sys/boot/uboot/Makefile.inc >> Index: /usr/src/sys/boot/uboot/Makefile.inc >> =================================================================== >> --- /usr/src/sys/boot/uboot/Makefile.inc (revision 292756) >> +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) >> @@ -2,7 +2,7 @@ >> >> .if ${MACHINE_ARCH} == "powerpc64" >> CFLAGS+= -m32 -mcpu=powerpc >> -LDFLAGS+= -m elf32ppc_fbsd >> +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd >> .endif >> >> .include "../Makefile.inc" > > All 3 are powerpc64 specific changes. > > === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"