Date: Mon, 28 Dec 2015 03:33:09 -0800 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Ian Lepore <ian@FreeBSD.org>, mat@FreeBSD.org, sbruno@FreeBSD.org 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? Message-ID: <9DA7895D-B3DE-41FD-900C-EC95BDE19728@dsl-only.net> In-Reply-To: <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net> References: <4CC6220D-72FB-45AD-AE70-5EB4EF0BCF5C@dsl-only.net> <DB75F0D6-86CB-4383-8653-6017C76729F9@dsl-only.net> <A338272B-982F-4E1F-B87D-1E33815EA212@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> <BBAAE33E-BD65-40A3-A0B3-F3346FC08112@dsl-only.net> <DC9EE7C3-2763-44EF-91DA-AFE63C48E537@dsl-only.net> <D38C49E3-B622-49EA-9B30-3B1B2FA2E569@bsdimp.com> <118D2970-4799-46B1-81A1-0101B907C1BE@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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>* =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/<unknown>)]
> (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<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=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 <markmi@dsl-only.net> wrote:
>=20
>=20
> On 2015-Dec-26, at 8:45 AM, Warner Losh <imp@bsdimp.com> 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 <markmi@dsl-only.net> =
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/<unknown>)]
>>>> (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 <iostream>
>> 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<guard_lock_t>(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9DA7895D-B3DE-41FD-900C-EC95BDE19728>