Re: Building with external toolchain was broken 6 months ago with r255187
On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs - fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty- body -Wno-error-parentheses-equality -Wno-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On Thu, 2014-03-20 at 10:08 -0400, John Baldwin wrote: On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs - fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty- body -Wno-error-parentheses-equality -Wno-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. But it's a module, built with -nostdinc, so the appropriate -I has to be on the command line. I notice that -no-aes is also on the command line, which seems like a strange thing for compiling a file named aeskeys_amd64. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we’re building the sysroot wrong then. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
Ian Lepore wrote this message on Thu, Mar 20, 2014 at 08:29 -0600: On Thu, 2014-03-20 at 10:08 -0400, John Baldwin wrote: On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote: On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote: Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400: I did't build my NanoBSD images for almost year, and in this time our not-finished and fragile support for using external toolchain is rotten, due to r255187 (and, may meb, some other commits too). I have very fresh -CURRENT (r263296) I have these settings for my buildworld buildkernel targets: XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp XAS=/usr/bin/as XAR=/usr/bin/ar XLD=/usr/bin/ld XNM=/usr/bin/nm XOBJDUMP=/usr/bin/objdump XRANLIB=/usr/bin/ranlib XSTRINGS=/usr/bin/strings COMPILER_TYPE=clang WITHOUT_CROSS_COMPILER=yes WITHOUT_BINUTILS=yes WITHOUT_CLANG=yes It worked 7 months ago. Now it works for buildworld but not for buildkernel: --- aeskeys_amd64.o --- /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp - B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS - include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ - I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame- pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx - mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno- asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs - fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty- body -Wno-error-parentheses-equality -Wno-unused-function-c /data/src/sys/modules/aesni/../../cryp to/aesni/aeskeys_amd64.S --- aesni_wrap.o --- In file included from /data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40: /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal error: 'wmmintrin.h' file not found #include wmmintrin.h ^ 1 error generated. *** [aesni_wrap.o] Error code 1 It could not find header file with intrinsics from system (external) clang. I could disable building of this module with WITHOUT_MODULES=aesni, and it works, but what if I need this module? Could it be fixed, pleeease? Sounds like your tool chain doesn't have the necessary support for AES-NI... Are you using gcc as cc? If so, do you have the necessary tool chain work that I did in r255185 in your local tree? The problem is that the kernel is deepening on a compiler header which is not in the right place in objdir if the compiler is not built. I thought I had reported this before (maybe just informally). I have been helping myself locally using this: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. But it's a module, built with -nostdinc, so the appropriate -I has to be on the command line. Actually, the above quoted text mixes two different files... aeskeys_amd64 is an assembly file so doesn't need the header... I notice that -no-aes is also on the command line, which seems like a strange thing for compiling a file named aeskeys_amd64. That's could be a bug in the assembler for allowing aes instructions when they are turned off... If it gets fixed, it isn't hard to enable them for this specific file.. If you look at aesni_wrap.c's build, you'll see it looks somethingl like: /usr/bin/cc -B/usr/obj/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -gdwarf-2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -Werror -mmmx -msse -maes
Re: Building with external toolchain was broken 6 months ago with r255187
Warner Losh wrote this message on Thu, Mar 20, 2014 at 11:30 -0600: On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we?re building the sysroot wrong then. I'm not familar w/ cross tools, are cross tools suppose to just work, or do you still require building kernel-toolchain? The wiki doesn't talk about buildkernel... If it's still required to build kernel-toolchain before buildkernel, one option is to remove the exclusion of the _includes target from kernel-toolchain, though _includes doesn't appear to install the header... It looks like it never goes into lib/clang to install them, though I'm not sure if it is suppose to or not.. If you use COMPILER_TYPE=gcc, it doesn't go into the proper gcc subdir to install them either... In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On Mar 20, 2014, at 12:24 PM, John-Mark Gurney j...@funkthat.com wrote: Warner Losh wrote this message on Thu, Mar 20, 2014 at 11:30 -0600: On Mar 20, 2014, at 8:25 AM, David Chisnall thera...@freebsd.org wrote: On 20 Mar 2014, at 14:08, John Baldwin j...@freebsd.org wrote: No, the compiler should provide a working wmmintrin.h header in one of its built-in paths if it supports the AES instructions. This is akin to saying that code that uses stdio.h should use -I/usr/src/include. It does, however our build system then explicitly says to the compiler 'don't use your built-it paths because they may contain declarations that contradict the FreeBSD ones' by means of the sysroot argument. When not using an external toolchain, we put the compiler's internal headers inside the sysroot. Sounds like we?re building the sysroot wrong then. I'm not familar w/ cross tools, are cross tools suppose to just work, or do you still require building kernel-toolchain? The wiki doesn't talk about buildkernel... If it's still required to build kernel-toolchain before buildkernel, one option is to remove the exclusion of the _includes target from kernel-toolchain, though _includes doesn't appear to install the header... It looks like it never goes into lib/clang to install them, though I'm not sure if it is suppose to or not.. If you use COMPILER_TYPE=gcc, it doesn't go into the proper gcc subdir to install them either… I’m saying that whatever is building the sysroot is building it wrong. I haven’t looked at the details enough to know where the fault lies. If the files aren’t there, that’s a bug and adding hacks for clang is not the right way to fix the bug. In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here That’s likely an orthogonal issue… Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On Thu, Mar 20, 2014 at 02:16:08PM -0600, Warner Losh wrote: On Mar 20, 2014, at 12:24 PM, John-Mark Gurney j...@funkthat.com wrote: In investigating this, it looks like we might have a make rule conflict in usr.sbin/bsdconfig... It has a subdir includes, but bsd.subdir.mk also defines a rule includes (for building inclues) which results in this: make[4]: /usr/src/share/mk/bsd.subdir.mk line 85: warning: duplicate script for target includes ignored make[4]: /usr/src/share/mk/bsd.subdir.mk line 69: warning: using previous script for includes defined here That’s likely an orthogonal issue… This is because usr.sbin/bsdconfig has an 'includes' SUBDIR entry. Glen pgpbV_Erz1qqa.pgp Description: PGP signature
Re: Building with external toolchain was broken 6 months ago with r255187
Hello, John-Mark.
You wrote 19 марта 2014 г., 2:01:40:
JMG Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
I did't build my NanoBSD images for almost year, and in this time our
not-finished and fragile support for using external toolchain is rotten,
due to r255187 (and, may meb, some other commits too).
I have very fresh -CURRENT (r263296)
I have these settings for my buildworld buildkernel targets:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
XAS=/usr/bin/as
XAR=/usr/bin/ar
XLD=/usr/bin/ld
XNM=/usr/bin/nm
XOBJDUMP=/usr/bin/objdump
XRANLIB=/usr/bin/ranlib
XSTRINGS=/usr/bin/strings
COMPILER_TYPE=clang
WITHOUT_CROSS_COMPILER=yes
WITHOUT_BINUTILS=yes
WITHOUT_CLANG=yes
It worked 7 months ago. Now it works for buildworld but not for
buildkernel:
--- aeskeys_amd64.o ---
/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp
-B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@
-I@/contrib/altq -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-unused-function-c
/data/src/sys/modules/aesni/../../crypto/aesni/aeskeys_amd64.S
--- aesni_wrap.o ---
In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
/data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
#include wmmintrin.h
^
1 error generated.
*** [aesni_wrap.o] Error code 1
It could not find header file with intrinsics from system (external)
clang. I could disable building of this module with WITHOUT_MODULES=aesni,
and it works, but what if I need this module?
Could it be fixed, pleeease?
JMG Sounds like your tool chain doesn't have the necessary support for
JMG AES-NI... Are you using gcc as cc? If so, do you have the necessary
JMG tool chain work that I did in r255185 in your local tree?
I use clang from world based on r263296 (amd64) to build world and kernel
from same r263296 (amd64) (as indicated earlier).
JMG Can you compile this test program?
Yes, of course. But kernel and modules are built with -sysroot option,
you know? And my -sysroot doesn't contains clang tree (and
/usr/include/clang/3.4), because it points to fresh world (in
OBJDIRPREFIX) and clang was not built for this world, I'm using system
one. It works for world, GENERIC kernel and all modules but aesni.
JMG -- tsse.c start
JMG #include wmmintrin.h
JMG __m128i foo;
JMG -- tsse.c end --
JMG With the command:
JMG ${XCC} -c -maes tsse.c
JMG If you can't, then the problem is your toolchain, and you need to fix
I can.
JMG it... Try also w/:
JMG clang -c -maes tsse.c
JMG and it's also helpful to know more info, like: ${XCC} --version
/usr/bin/cc --version
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: x86_64-unknown-freebsd11.0
Thread model: posix
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
Hello, John-Mark. You wrote 19 марта 2014 г., 2:36:38: JMG This still sounds like the compiler being used isn't installed JMG properly... I've never had a problem when a proper kernel-toolchain JMG is available to build the kernel with... JMG If someone is willing to provide me w/ detailed instructions or an image JMG that reproduces the issue, I'm willing to look at it... Try this: /usr/src/tools/tools/nanopbsd/nanobsd.sh -c aesni-problem.nanobsd with attached aesni-problem.nanobsd file. If you add WITHOUT_MODULES=aesni to CONF_WORLD variable it will work. You may want to check first two variables in this script. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org aesni-problem.nanobsd Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
I did't build my NanoBSD images for almost year, and in this time our
not-finished and fragile support for using external toolchain is rotten,
due to r255187 (and, may meb, some other commits too).
I have very fresh -CURRENT (r263296)
I have these settings for my buildworld buildkernel targets:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
XAS=/usr/bin/as
XAR=/usr/bin/ar
XLD=/usr/bin/ld
XNM=/usr/bin/nm
XOBJDUMP=/usr/bin/objdump
XRANLIB=/usr/bin/ranlib
XSTRINGS=/usr/bin/strings
COMPILER_TYPE=clang
WITHOUT_CROSS_COMPILER=yes
WITHOUT_BINUTILS=yes
WITHOUT_CLANG=yes
It worked 7 months ago. Now it works for buildworld but not for
buildkernel:
--- aeskeys_amd64.o ---
/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp
-B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@
-I@/contrib/altq -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function
-c /data/src/sys/modules/aesni/../../cryp
to/aesni/aeskeys_amd64.S
--- aesni_wrap.o ---
In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
/data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
#include wmmintrin.h
^
1 error generated.
*** [aesni_wrap.o] Error code 1
It could not find header file with intrinsics from system (external)
clang. I could disable building of this module with WITHOUT_MODULES=aesni,
and it works, but what if I need this module?
Could it be fixed, pleeease?
Sounds like your tool chain doesn't have the necessary support for
AES-NI... Are you using gcc as cc? If so, do you have the necessary
tool chain work that I did in r255185 in your local tree?
Can you compile this test program?
-- tsse.c start
#include wmmintrin.h
__m128i foo;
-- tsse.c end --
With the command:
${XCC} -c -maes tsse.c
If you can't, then the problem is your toolchain, and you need to fix
it... Try also w/:
clang -c -maes tsse.c
and it's also helpful to know more info, like: ${XCC} --version
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote:
Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
I did't build my NanoBSD images for almost year, and in this time our
not-finished and fragile support for using external toolchain is rotten,
due to r255187 (and, may meb, some other commits too).
I have very fresh -CURRENT (r263296)
I have these settings for my buildworld buildkernel targets:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
XAS=/usr/bin/as
XAR=/usr/bin/ar
XLD=/usr/bin/ld
XNM=/usr/bin/nm
XOBJDUMP=/usr/bin/objdump
XRANLIB=/usr/bin/ranlib
XSTRINGS=/usr/bin/strings
COMPILER_TYPE=clang
WITHOUT_CROSS_COMPILER=yes
WITHOUT_BINUTILS=yes
WITHOUT_CLANG=yes
It worked 7 months ago. Now it works for buildworld but not for
buildkernel:
--- aeskeys_amd64.o ---
/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp
-B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@
-I@/contrib/altq -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-unused-function-c
/data/src/sys/modules/aesni/../../cryp
to/aesni/aeskeys_amd64.S
--- aesni_wrap.o ---
In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
/data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
#include wmmintrin.h
^
1 error generated.
*** [aesni_wrap.o] Error code 1
It could not find header file with intrinsics from system (external)
clang. I could disable building of this module with WITHOUT_MODULES=aesni,
and it works, but what if I need this module?
Could it be fixed, pleeease?
Sounds like your tool chain doesn't have the necessary support for
AES-NI... Are you using gcc as cc? If so, do you have the necessary
tool chain work that I did in r255185 in your local tree?
The problem is that the kernel is deepening on a compiler header which is not
in the right place in objdir if the compiler is not built. I thought I had
reported this before (maybe just informally). I have been helping myself
locally using this:
Index: sys/modules/aesni/Makefile
===
--- sys/modules/aesni/Makefile (revision 263176)
+++ sys/modules/aesni/Makefile (working copy)
@@ -11,7 +11,8 @@ OBJS+=aesni_wrap.o
# Remove -nostdinc so we can get the intrinsics.
aesni_wrap.o: aesni_wrap.c
- ${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
+ ${CC} -I${.CURDIR}/../../../contrib/llvm/tools/clang/lib/Headers \
+-c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
-mmmx -msse -maes ${.IMPSRC}
${CTFCONVERT_CMD}
—
Bjoern A. Zeeb ? ??? ??? ??:
'??? ??? ?? ??? ?? ?? ??? ??? ??? ? ?
?? ?? ? ', ? ?, ??? ? ?? ?, ?.???
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Building with external toolchain was broken 6 months ago with r255187
Bjoern A. Zeeb wrote this message on Tue, Mar 18, 2014 at 22:20 +:
On 18 Mar 2014, at 22:01 , John-Mark Gurney j...@funkthat.com wrote:
Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
I did't build my NanoBSD images for almost year, and in this time our
not-finished and fragile support for using external toolchain is rotten,
due to r255187 (and, may meb, some other commits too).
I have very fresh -CURRENT (r263296)
I have these settings for my buildworld buildkernel targets:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
XAS=/usr/bin/as
XAR=/usr/bin/ar
XLD=/usr/bin/ld
XNM=/usr/bin/nm
XOBJDUMP=/usr/bin/objdump
XRANLIB=/usr/bin/ranlib
XSTRINGS=/usr/bin/strings
COMPILER_TYPE=clang
WITHOUT_CROSS_COMPILER=yes
WITHOUT_BINUTILS=yes
WITHOUT_CLANG=yes
It worked 7 months ago. Now it works for buildworld but not for
buildkernel:
--- aeskeys_amd64.o ---
/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp
-B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@
-I@/contrib/altq -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-unused-function-c /data/src/sys/modules/aesni/../../c
ryp
to/aesni/aeskeys_amd64.S
--- aesni_wrap.o ---
In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
/data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
#include wmmintrin.h
^
1 error generated.
*** [aesni_wrap.o] Error code 1
It could not find header file with intrinsics from system (external)
clang. I could disable building of this module with WITHOUT_MODULES=aesni,
and it works, but what if I need this module?
Could it be fixed, pleeease?
Sounds like your tool chain doesn't have the necessary support for
AES-NI... Are you using gcc as cc? If so, do you have the necessary
tool chain work that I did in r255185 in your local tree?
The problem is that the kernel is deepening on a compiler header which is not
in the right place in objdir if the compiler is not built. I thought I had
reported this before (maybe just informally). I have been helping myself
locally using this:
This still sounds like the compiler being used isn't installed
properly... I've never had a problem when a proper kernel-toolchain
is available to build the kernel with...
If someone is willing to provide me w/ detailed instructions or an image
that reproduces the issue, I'm willing to look at it...
Index: sys/modules/aesni/Makefile
===
--- sys/modules/aesni/Makefile(revision 263176)
+++ sys/modules/aesni/Makefile(working copy)
@@ -11,7 +11,8 @@ OBJS+= aesni_wrap.o
# Remove -nostdinc so we can get the intrinsics.
aesni_wrap.o: aesni_wrap.c
- ${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
+ ${CC} -I${.CURDIR}/../../../contrib/llvm/tools/clang/lib/Headers \
+ -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} \
-mmmx -msse -maes ${.IMPSRC}
${CTFCONVERT_CMD}
This change breaks building w/ gcc
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
