Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Mark Millard]

On 2016-Jan-10, at 9:59 AM, Mark Millard  wrote:
> 
> [A top post of my so far successful experiment. . .]
> 
> amd64 -> rpi2 cross build: buildworld buildkernel installkernel installworld 
> mergemaster delete-old then boot the result on an rpi2 worked ( -march=armv7a 
> -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access used ).
> 
> In order to also build lldb I used the following beyond what Ian sent out for 
> -mlong-calls usage:
> (I make no claim to have tested the lldb build.)
> (Tabs likely not preserved in the copy/paste operations.)
> 
>> # more lib_libc++_Makfile.diff 
>> Index: /usr/src/lib/libc++/Makefile
>> ===
>> --- /usr/src/lib/libc++/Makefile(revision 293430)
>> +++ /usr/src/lib/libc++/Makefile(working copy)
>> @@ -57,6 +57,9 @@
>> .endfor
>> 
>> WARNS= 0
>> +.if ${MACHINE_CPUARCH} == "arm"
>> +STATIC_CXXFLAGS+=-mlong-calls
>> +.endif
>> CFLAGS+=   -I${HDRDIR} -I${_LIBCXXRTDIR} -nostdlib -DLIBCXXRT
>> .if empty(CXXFLAGS:M-std=*)
>> CXXFLAGS+= -std=c++11
> 
>> # more usr_bin_clang_lldb_Makefile.diff 
>> Index: /usr/src/usr.bin/clang/lldb/Makefile
>> ===
>> --- /usr/src/usr.bin/clang/lldb/Makefile(revision 293430)
>> +++ /usr/src/usr.bin/clang/lldb/Makefile(working copy)
>> @@ -6,6 +6,10 @@
>> 
>> LLDB_SRCS=${.CURDIR}/../../../contrib/llvm/tools/lldb
>> 
>> +.if ${MACHINE_CPUARCH} == "arm"
>> +CFLAGS+=-mlong-calls
>> +.endif
>> +
>> CFLAGS+=   -I${LLDB_SRCS}/include
>> CXXFLAGS+= -std=c++11
> 
> 
> 
> The rpi2 is now attempting buildworld buildkernel targeting itself. It is way 
> beyond where clang 3.7.1 crashed.



The rpi2 finished buildworld buildkernel. To build:

> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_LLDB=
> WITH_CLANG_EXTRAS=
> WITH_BOOT=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_CLANG_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_LIB32=
> WITHOUT_GCC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG=
> WITH_DEBUG_FILES=

based on -target armv6--freebsd11.0-gnueabi -march=armv7a -mcpu=cortex-a7 
-mfloat-abi=softfp -mno-unaligned-access it took the rpi2 14 hours 26 min or so.

Then: installkernel; install world; shutdown -r now . . .

. . . It boots and operates as hoped. For this rpi2 context clang 3.8.0 seems 
to be working fine for such activity.

> # freebsd-version -ku; uname -aKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r293579M: Mon Jan 11 
> 07:36:21 UTC 2016 
> markmi@rpi2:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm 1100093 
> 1100093
> make.conf empty.

src.conf (make.conf empty):

> TO_TYPE=armv6
> #
> KERNCONF=RPI2-NODBG
> TARGET=arm
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_LLDB=
> WITH_CLANG_EXTRAS=
> WITH_BOOT=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_CLANG_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_LIB32=
> WITHOUT_GCC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> #
> .if ${.MAKE.LEVEL} == 0
> XCC=/usr/bin/clang -v -target ${TO_TYPE}--freebsd11.0-gnueabi -march=armv7a 
> -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access
> XCXX=/usr/bin/clang++ -v -target ${TO_TYPE}--freebsd11.0-gnueabi 
> -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access
> XCPP=/usr/bin/clang-cpp -v -target ${TO_TYPE}--freebsd11.0-gnueabi 
> -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access
> .export XCC
> .export XCXX
> .export XCPP
> .endif
> #
> .if ${.MAKE.LEVEL} == 0
> CC=/usr/bin/clang -v -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp 
> -mno-unaligned-access
> CXX=/usr/bin/clang++ -v -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp 
> -mno-unaligned-access
> CPP=/usr/bin/clang-cpp -v -march=armv7a -mcpu=cortex-a7 -mfloat-abi=softfp 
> -mno-unaligned-access
> .export CC
> .export CXX
> .export CPP
> .endif

This vintage of src.conf presumes Ian Lepore's updates to the system's binutils 
that allow them to handle armv7a movt instruction usage and the like.


RPI2-NODBG:

> ident   RPI2-NODBG
> 
> include "RPI2"
> 
> makeoptions DEBUG=-g# Build kernel with gdb(1) debug 
> symbols
> options ALT_BREAK_TO_DEBUGGER
> #optionsVERBOSE_SYSINIT # Enable verbose sysinit messages
> 
> options KDB # Enable kernel debugger support
> 
> # For minimum debugger support (stable branch) use:
> #optionsKDB_TRACE   # Print a stack trace for a panic
> options DDB # Enable the kernel debugger
> 
> nooptions   INVARIANTS  # Enable 

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Mark Millard]

On 2016-Jan-9, at 10:55 AM, Ian Lepore  wrote:
> 
> On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote:
>> On 09 Jan 2016, at 04:46, Mark Millard  wrote:
>>> 
>>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric 
>>> wrote:
>> ...
 FYI, I have added a -mno-movt option for this purpose upstream,
 and
 imported a newer snapshot into the clang380-import branch.  As of
 r293384, it now uses the new option spelling for modules, if your
 clang
 is 3.8.0 or higher.
 
 -Dimitry
>>> 
>>> I've not been able to get to the point of running clang++ 3.8 on
>>> the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations
>>> during the cross build's buildworld interfere.
>> 
>> Yes, this is caused by too large call distances.  In other words, the
>> clang executable is getting to big to link.  Apparently we need to do
>> some tricks with -mlongcall to fix this.  As I am no arm expert, I
>> welcome any patch submissions. :-)
>> 
>> -Dimitry
>> 
> 
> Here's the patch I got from Andy for the clang380 branch, modified with
> Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE.  With
> this I can get a working arm world that will build a runnable
> helloworld.c (and .cc) on a dreamplug.  (I.e., it appears clang 3.8.0
> fixes the problem we had with clang 3.7.x where it wouldn't run at all
> on armv4/5 systems).  I have not tried compling anything complex yet.
> 
> -- Ian


Context: When I build I normally build lldb and the like as well, even using 
WITH_CLANG_EXTRAS= .

In trying to get lldb to link I eventually get to the point that libc++ is 
getting relocation truncations. Before getting to that I deal with 
/usr/src/usr.bin/clang/lldb/Makefile to cover what is initially reported during 
buildworld for lldb relocation truncations. Then with that in place and 
retrying I get reports from libc++.a for a couple of the contained .o files 
having relocations that are truncated (before it reports "additional relocation 
overflows omitted from the output"):

/usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o)
/usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o)

(Both have messages from multiple places in each .o file.)

As far as I can tell for general use -long-calls is going to be needed for at 
least some system level .a library content if the .a's are to be used.

Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for arm system 
libraries fairly generally is appropriate for those intending on building the 
arm-native clang toolchain  and related material in buildworld. (STATIC_CFLAGS 
too?) A significant case analysis of what happens to currently be too far apart 
would be fragile as things grow even more later.

This sort of issue may well not be limited to TARGET=arm contexts.

The detailed libc++.a relocation truncation complaints that I got were:


> --- all_subdir_lldb ---
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In function 
> `_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_':
> /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_[_ZNSt3__16vectorINS_4pairIPNS_18condition_variableEPNS_5mutexEEENS_18__hidden_allocatorIS6_EEE21__push_back_slow_pathIS6_EEvOT_]+0x30):
>  relocation truncated to fit: R_ARM_CALL against symbol 
> `std::__1::__vector_base_common::__throw_length_error() const' defined 
> in 
> .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv]
>  section in 
> /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/liblldbCore/liblldbCore.a(CxaDemangle.o)

> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o): In function 
> `_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_':
> /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp:(.text._ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_[_ZNSt3__16vectorIPNS_17__assoc_sub_stateENS_18__hidden_allocatorIS2_EEE21__push_back_slow_pathIRKS2_EEvOT_]+0x30):
>  relocation truncated to fit: R_ARM_CALL against symbol 
> `std::__1::__vector_base_common::__throw_length_error() const' defined 
> in 
> .text._ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv[_ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv]
>  section in 
> /usr/obj/clang/arm.armv6/usr/src/usr.bin/clang/lldb/../../../lib/clang/liblldbCore/liblldbCore.a(CxaDemangle.o)

. . .
> --- all_subdir_clang ---
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o): In function 
> `std::__1::collate_byname::do_compare(char const*, char const*, char 
> const*, char const*) const':
. . .
> --- 

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Mark Millard]

[A top post of my so far successful experiment. . .]

amd64 -> rpi2 cross build: buildworld buildkernel installkernel installworld 
mergemaster delete-old then boot the result on an rpi2 worked ( -march=armv7a 
-mcpu=cortex-a7 -mfloat-abi=softfp -mno-unaligned-access used ).

In order to also build lldb I used the following beyond what Ian sent out for 
-mlong-calls usage:
(I make no claim to have tested the lldb build.)
(Tabs likely not preserved in the copy/paste operations.)

> # more lib_libc++_Makfile.diff 
> Index: /usr/src/lib/libc++/Makefile
> ===
> --- /usr/src/lib/libc++/Makefile(revision 293430)
> +++ /usr/src/lib/libc++/Makefile(working copy)
> @@ -57,6 +57,9 @@
>  .endfor
>  
>  WARNS= 0
> +.if ${MACHINE_CPUARCH} == "arm"
> +STATIC_CXXFLAGS+=-mlong-calls
> +.endif
>  CFLAGS+=   -I${HDRDIR} -I${_LIBCXXRTDIR} -nostdlib -DLIBCXXRT
>  .if empty(CXXFLAGS:M-std=*)
>  CXXFLAGS+= -std=c++11

> # more usr_bin_clang_lldb_Makefile.diff 
> Index: /usr/src/usr.bin/clang/lldb/Makefile
> ===
> --- /usr/src/usr.bin/clang/lldb/Makefile(revision 293430)
> +++ /usr/src/usr.bin/clang/lldb/Makefile(working copy)
> @@ -6,6 +6,10 @@
>  
>  LLDB_SRCS=${.CURDIR}/../../../contrib/llvm/tools/lldb
>  
> +.if ${MACHINE_CPUARCH} == "arm"
> +CFLAGS+=-mlong-calls
> +.endif
> +
>  CFLAGS+=   -I${LLDB_SRCS}/include
>  CXXFLAGS+= -std=c++11
 


The rpi2 is now attempting buildworld buildkernel targeting itself. It is way 
beyond where clang 3.7.1 crashed.


The above makes no claim at investigating or addressing powerpc64 (PowerMac G5) 
or powerpc (PowerMac G4/G3) yet(?). So far as I know clang mixed with the 
available supporting toolchain alternatives are still insufficient for 
targeting those for a WITH_LIBCPLUSPLUS= build. Instead something like 
powerpc64-xtoolchain-gcc/powerpc64-gcc must be used, even if clang is built. 
(Last I knew gcc5 variations/vintages would reject some of the 
WITH_CLANG_EXTRAS= code --but I've not tried based on clang 3.8.0 materials.)



===
Mark Millard
markmi at dsl-only.net

On 2016-Jan-10, at 3:55 AM, Mark Millard  wrote:
> 
> 
> On 2016-Jan-9, at 10:55 AM, Ian Lepore  wrote:
>> 
>> On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote:
>>> On 09 Jan 2016, at 04:46, Mark Millard  wrote:
 
 On 2016-Jan-7, at 2:57 PM, Dimitry Andric 
 wrote:
>>> ...
> FYI, I have added a -mno-movt option for this purpose upstream,
> and
> imported a newer snapshot into the clang380-import branch.  As of
> r293384, it now uses the new option spelling for modules, if your
> clang
> is 3.8.0 or higher.
> 
> -Dimitry
 
 I've not been able to get to the point of running clang++ 3.8 on
 the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations
 during the cross build's buildworld interfere.
>>> 
>>> Yes, this is caused by too large call distances.  In other words, the
>>> clang executable is getting to big to link.  Apparently we need to do
>>> some tricks with -mlongcall to fix this.  As I am no arm expert, I
>>> welcome any patch submissions. :-)
>>> 
>>> -Dimitry
>>> 
>> 
>> Here's the patch I got from Andy for the clang380 branch, modified with
>> Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE.  With
>> this I can get a working arm world that will build a runnable
>> helloworld.c (and .cc) on a dreamplug.  (I.e., it appears clang 3.8.0
>> fixes the problem we had with clang 3.7.x where it wouldn't run at all
>> on armv4/5 systems).  I have not tried compling anything complex yet.
>> 
>> -- Ian
> 
> 
> Context: When I build I normally build lldb and the like as well, even using 
> WITH_CLANG_EXTRAS= .
> 
> In trying to get lldb to link I eventually get to the point that libc++ is 
> getting relocation truncations. Before getting to that I deal with 
> /usr/src/usr.bin/clang/lldb/Makefile to cover what is initially reported 
> during buildworld for lldb relocation truncations. Then with that in place 
> and retrying I get reports from libc++.a for a couple of the contained .o 
> files having relocations that are truncated (before it reports "additional 
> relocation overflows omitted from the output"):
> 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(thread.o)
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(locale.o)
> 
> (Both have messages from multiple places in each .o file.)
> 
> As far as I can tell for general use -long-calls is going to be needed for at 
> least some system level .a library content if the .a's are to be used.
> 
> Which leaves me wondering if STATIC_CXXFLAGS having -mlong-calls for arm 
> system libraries fairly generally is appropriate for those intending on 
> building the arm-native clang toolchain  and related material in buildworld. 
> (STATIC_CFLAGS too?) A significant case analysis of what happens to 

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Dimitry Andric]

On 09 Jan 2016, at 04:46, Mark Millard  wrote:
> 
> On 2016-Jan-7, at 2:57 PM, Dimitry Andric  wrote:
...
>> FYI, I have added a -mno-movt option for this purpose upstream, and
>> imported a newer snapshot into the clang380-import branch.  As of
>> r293384, it now uses the new option spelling for modules, if your clang
>> is 3.8.0 or higher.
>> 
>> -Dimitry
> 
> I've not been able to get to the point of running clang++ 3.8 on the rpi2 
> yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations during the cross 
> build's buildworld interfere.

Yes, this is caused by too large call distances.  In other words, the
clang executable is getting to big to link.  Apparently we need to do
some tricks with -mlongcall to fix this.  As I am no arm expert, I
welcome any patch submissions. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Ian Lepore]

On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote:
> On 09 Jan 2016, at 04:46, Mark Millard  wrote:
> > 
> > On 2016-Jan-7, at 2:57 PM, Dimitry Andric 
> > wrote:
> ...
> > > FYI, I have added a -mno-movt option for this purpose upstream,
> > > and
> > > imported a newer snapshot into the clang380-import branch.  As of
> > > r293384, it now uses the new option spelling for modules, if your
> > > clang
> > > is 3.8.0 or higher.
> > > 
> > > -Dimitry
> > 
> > I've not been able to get to the point of running clang++ 3.8 on
> > the rpi2 yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations
> > during the cross build's buildworld interfere.
> 
> Yes, this is caused by too large call distances.  In other words, the
> clang executable is getting to big to link.  Apparently we need to do
> some tricks with -mlongcall to fix this.  As I am no arm expert, I
> welcome any patch submissions. :-)
> 
> -Dimitry
> 

Here's the patch I got from Andy for the clang380 branch, modified with
Warner's suggestion to use MACHINE_CPUARCH instead of MACHINE.  With
this I can get a working arm world that will build a runnable
helloworld.c (and .cc) on a dreamplug.  (I.e., it appears clang 3.8.0
fixes the problem we had with clang 3.7.x where it wouldn't run at all
on armv4/5 systems).  I have not tried compling anything complex yet.

-- Ian
Index: lib/clang/clang.lib.mk
===
--- lib/clang/clang.lib.mk	(revision 293584)
+++ lib/clang/clang.lib.mk	(working copy)
@@ -6,4 +6,8 @@ LLVM_SRCS= ${.CURDIR}/../../../contrib/llvm
 
 INTERNALLIB=
 
+.if ${MACHINE_CPUARCH} == "arm"
+STATIC_CXXFLAGS+=-mlong-calls
+.endif
+
 .include 
Index: lib/csu/arm/Makefile
===
--- lib/csu/arm/Makefile	(revision 293584)
+++ lib/csu/arm/Makefile	(working copy)
@@ -23,7 +23,7 @@ CLEANFILES+=	crt1.s gcrt1.s Scrt1.s
 # directly compiled to .o files.
 
 crt1.s: crt1.c
-	${CC} ${CFLAGS} -S -o ${.TARGET} ${.CURDIR}/crt1.c
+	${CC} ${CFLAGS} -mlong-calls -S -o ${.TARGET} ${.CURDIR}/crt1.c
 	sed ${SED_FIX_NOTE} ${.TARGET}
 
 crt1.o: crt1.s
@@ -30,7 +30,7 @@ crt1.o: crt1.s
 	${CC} ${ACFLAGS} -c -o ${.TARGET} crt1.s
 
 gcrt1.s: crt1.c
-	${CC} ${CFLAGS} -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c
+	${CC} ${CFLAGS} -mlong-calls -DGCRT -S -o ${.TARGET} ${.CURDIR}/crt1.c
 	sed ${SED_FIX_NOTE} ${.TARGET}
 
 gcrt1.o: gcrt1.s
Index: usr.bin/clang/clang/Makefile
===
--- usr.bin/clang/clang/Makefile	(revision 293584)
+++ usr.bin/clang/clang/Makefile	(working copy)
@@ -11,7 +11,11 @@ SRCS=	cc1_main.cpp \
 
 .if ${MK_SHARED_TOOLCHAIN} == "no"
 NO_SHARED?= yes
+
+.if ${MACHINE_CPUARCH} == "arm"
+CFLAGS+=-mlong-calls
 .endif
+.endif
 
 LINKS=	${BINDIR}/clang ${BINDIR}/clang++ \
 	${BINDIR}/clang ${BINDIR}/clang-cpp
___
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"

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Mark Millard]

On 2016-Jan-7, at 2:57 PM, Dimitry Andric  wrote:
> 
> On 05 Jan 2016, at 19:53, Ian Lepore  wrote:
>> 
>> On Tue, 2016-01-05 at 11:35 -0700, Warner Losh wrote:
> ...
>>> There's a projects/clang-380-import that you might want to try...
>> 
>> It's a non-starter for us, because unfortunately they appear to have
>> removed support for the -arm-use-movt=0 command line option, so now we
>> can't build ubldr or kernel modules.
> 
> FYI, I have added a -mno-movt option for this purpose upstream, and
> imported a newer snapshot into the clang380-import branch.  As of
> r293384, it now uses the new option spelling for modules, if your clang
> is 3.8.0 or higher.
> 
> -Dimitry

I've not been able to get to the point of running clang++ 3.8 on the rpi2 yet: 
R_ARM_CALL and R_ARM_JUMP24 relocation truncations during the cross build's 
buildworld interfere.

I've no clue just what you expect the status of things to be so this note is 
just an FYI on what happened when I tried to cross build from an amd64 context 
targetting an armv6 context, also using "-march=armv7a -mcpu=cortex-a7 
-mno-unaligned-access".



Yesterday I cloned an amd64 virtual box virtual machine that I run FreeBSD 
11.0-CURRENT in  and updated the cloned copy's /usr/src/ to 
base/projects/clang380-import -r293417. buildworld, buildkernel and the 
installs for amd64 went fine.

Then today I updated /usr/src to -r293430 and attempted buildworld buildkernel 
targeting armv6 with "-march=armv7a -mcpu=cortex-a7 -mno-unaligned-access". I 
ended up with:

> --- all_subdir_clang ---
> clang++: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> *** [clang.full] Error code 1

Looking in the script output I find relocation truncation notices for 
R_ARM_CALL and R_ARM_JUMP24 usage:

> --- all_subdir_usr.bin ---
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/crt1.o: In function `__start':
. . .
> --- all_subdir_usr.bin ---
> /usr/src/lib/csu/arm/crt1.c:(.text+0xc4): relocation truncated to fit: 
> R_ARM_CALL against symbol `atexit' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc.a(atexit.o)
. . .
> --- all_subdir_usr.bin ---
> /usr/src/lib/csu/arm/crt1.c:(.text+0xcc): relocation truncated to fit: 
> R_ARM_CALL against symbol `_init_tls' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc.a(tls.o)
> /usr/src/lib/csu/arm/crt1.c:(.text+0xe0): relocation truncated to fit: 
> R_ARM_CALL against symbol `atexit' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc.a(atexit.o)
> /usr/src/lib/csu/arm/crt1.c:(.text+0x19c): relocation truncated to fit: 
> R_ARM_JUMP24 against symbol `exit' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc.a(exit.o)
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/crt1.o: In function `finalizer':
> /usr/src/lib/csu/arm/crt1.c:(.text+0x1f8): relocation truncated to fit: 
> R_ARM_JUMP24 against symbol `_fini' defined in .fini section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/crti.o

. . .
> --- all_subdir_usr.bin ---
> cc1_main.o: In function `cc1_main(llvm::ArrayRef, char const*, 
> void*)':
. . .
> --- all_subdir_usr.bin ---
> /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:68:
>  relocation truncated to fit: R_ARM_CALL against symbol `operator 
> new(unsigned int)' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(new.o)
. . .
> --- all_subdir_usr.bin ---
> cc1_main.o: In function `std::__1::__allocate(unsigned int)':
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/include/c++/v1/new:168: relocation 
> truncated to fit: R_ARM_CALL against symbol `operator new(unsigned int)' 
> defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(new.o)
. . .
> --- all_subdir_usr.bin ---
> cc1_main.o: In function `~shared_ptr':
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/include/c++/v1/memory:4567: 
> relocation truncated to fit: R_ARM_CALL against symbol 
> `std::__1::__shared_weak_count::__release_shared()' defined in .text section 
> in /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(memory.o)
> cc1_main.o: In function `cc1_main(llvm::ArrayRef, char const*, 
> void*)':
> /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:69:
>  relocation truncated to fit: R_ARM_CALL against symbol `operator 
> new(unsigned int)' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(new.o)
> cc1_main.o: In function `shared_ptr':
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/include/c++/v1/memory:4254: 
> relocation truncated to fit: R_ARM_CALL against symbol 
> `std::__1::__shared_weak_count::__add_shared()' defined in .text section in 
> /usr/obj/clang/arm.armv6/usr/src/tmp/usr/lib/libc++.a(memory.o)
> cc1_main.o: In function 
> 

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Ian Lepore]

On Thu, 2016-01-07 at 23:57 +0100, Dimitry Andric wrote:
> On 05 Jan 2016, at 19:53, Ian Lepore  wrote:
> > 
> > On Tue, 2016-01-05 at 11:35 -0700, Warner Losh wrote:
> ...
> > > There's a projects/clang-380-import that you might want to try...
> > 
> > It's a non-starter for us, because unfortunately they appear to
> > have
> > removed support for the -arm-use-movt=0 command line option, so now
> > we
> > can't build ubldr or kernel modules.
> 
> FYI, I have added a -mno-movt option for this purpose upstream, and
> imported a newer snapshot into the clang380-import branch.  As of
> r293384, it now uses the new option spelling for modules, if your
> clang
> is 3.8.0 or higher.
> 
> -Dimitry
> 

I've updated to that and I'm still getting this error:

cc1_main.o: In function `ForcePassLinking':
[...]/src/usr.bin/clang/clang/../../../contrib/llvm/include/llvm/LinkAllPasses.h:194:
 undefined reference to `llvm::sys::RunningOnValgrind()'
c++: error: linker command failed with exit code 1 (use -v to see invocation)
--- clang.full ---
*** [clang.full] Error code 1

I can apparently make it go away just by commenting out the line it
complains about, so I'm forging ahead with that for now to see if I can
do more testing.

-- Ian

___
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"

Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Mark Millard]

llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 will 
contain the fixes:

James Molloy changed bug 25958 
WhatRemoved Added
Status  NEW RESOLVED
Resolution  --- FIXED
Comment # 8 on bug 25958 from James Molloy
Hi Mark,

Thanks for your detailed investigation. I can confirm that this is fixed on
trunk and therefore will be fixed for LLVM 3.8.

The fixes were done for SPARC, which requires strict accesses much as ARM does
with SCTLR=1.

There was a sequence of commits by James Knight that fixed these, but an
example is http://reviews.llvm.org/rL242554 .

The fixes were in a similar vein to yours, but required changes in fewer places
and there were a few more sticky issues to solve too. I'll CC James here in
case he wants to comment on the current state of the clang codebase for
self-hosting in a strict alignment environment.

Cheers,

James

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

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Warner Losh]

On Tue, Jan 5, 2016 at 11:27 AM, Mark Millard  wrote:

> llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8
> will contain the fixes:
>
> James Molloy changed bug 25958
> WhatRemoved Added
> Status  NEW RESOLVED
> Resolution  --- FIXED
> Comment # 8 on bug 25958 from James Molloy
> Hi Mark,
>
> Thanks for your detailed investigation. I can confirm that this is fixed on
> trunk and therefore will be fixed for LLVM 3.8.
>
> The fixes were done for SPARC, which requires strict accesses much as ARM
> does
> with SCTLR=1.
>
> There was a sequence of commits by James Knight that fixed these, but an
> example is http://reviews.llvm.org/rL242554 .
>
> The fixes were in a similar vein to yours, but required changes in fewer
> places
> and there were a few more sticky issues to solve too. I'll CC James here in
> case he wants to comment on the current state of the clang codebase for
> self-hosting in a strict alignment environment.
>
> Cheers,
>
> James
>

There's a projects/clang-380-import that you might want to try...

Warner
___
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"