On 2015-Dec-28, at 3:33 AM, Mark Millard <[email protected]> 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 <[email protected]> wrote:
>
>
> On 2015-Dec-26, at 8:45 AM, Warner Losh <[email protected]> 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 <[email protected]> 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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "[email protected]"
