[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.
===
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"
