Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[Brooks Davis]

On Tue, Aug 30, 2016 at 02:50:03PM -0700, Matthew Macy wrote:
> 
> 
> 
>   On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis  
> wrote  
>  > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
>  > > It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed: 
>  > >  
>  > >  
>  > > This works: 
>  > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
>  > >  
>  > > This fails: 
>  > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
>  > >  
>  > > with: 
>  > >  
>  > > 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory 
>  > > clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation) 
>  >  
>  > I've fixed the install problem.  I'm rather confused about why clang 
>  > would try to link with sanitizer libraries when building source.  That's 
>  > certainly not default behavior. 
>  
> Thanks for the extremely prompt response to both issues. I haven't figured 
> out why svn has problems but the libc/tests failure can be traced back to the 
> following commit:
> 
> commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
> Author: ngie 
> Date:   Fri Jan 2 05:40:02 2015 +
> 
> Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 
> Jenkins
> job
> 
> The h_raw application doesn't do proper bounds checking without the option
> being supplied via the build, which means that it doesn't throw signals 
> and
> fail as expected
> 
> PR: 196430
> X-MFC with: r276479
> 
> diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh 
> b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> index 04adc67..362178f 100755
> --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> @@ -360,6 +360,9 @@ raw_head()
>  raw_body()
>  {
> prog="$(atf_get_srcdir)/h_raw"
> +   # Begin FreeBSD
> +   [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
> +   # End FreeBSD
>  
> h_pass "$prog 9"
> # Begin FreeBSD
> diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
> index 1649cc2..7bc8660 100644
> --- a/lib/libc/tests/ssp/Makefile
> +++ b/lib/libc/tests/ssp/Makefile
> @@ -9,10 +9,7 @@ WARNS?=2
>  
>  CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
>  .if ${COMPILER_TYPE} == "clang"
> -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
> -.if ${COMPILER_VERSION} < 30500
>  CFLAGS.h_raw+= -fsanitize=bounds
> -.endif

Thanks for hunting this down.

There's no strong reason to assume that a given clang has sanitizers
available.  In the current build system, you need a clang tree to build
the sanitizers, but the build process is separate.  If we're going to
enable sanitizers in tests, we need to do so conditionally so we don't
break the tests on non-x86 systems and so compiler installs don't need
to provide them.

-- Brooks


signature.asc
Description: PGP signature

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[Matthew Macy]

  On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis  
wrote  
 > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
 > > It looks like there is something broken with the devel/llvm38 port or 
 > > external toolchain support has regressed: 
 > >  
 > >  
 > > This works: 
 > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
 > > XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
 > >  
 > > This fails: 
 > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
 > > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
 > >  
 > > with: 
 > >  
 > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
 > >  
 > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
 > >  No such file: No such file or directory 
 > > clang-3.8: error: linker command failed with exit code 1 (use -v to see 
 > > invocation) 
 >  
 > I've fixed the install problem.  I'm rather confused about why clang 
 > would try to link with sanitizer libraries when building source.  That's 
 > certainly not default behavior. 
 
Thanks for the extremely prompt response to both issues. I haven't figured out 
why svn has problems but the libc/tests failure can be traced back to the 
following commit:

commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
Author: ngie 
Date:   Fri Jan 2 05:40:02 2015 +

Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 
Jenkins
job

The h_raw application doesn't do proper bounds checking without the option
being supplied via the build, which means that it doesn't throw signals and
fail as expected

PR: 196430
X-MFC with: r276479

diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh 
b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
index 04adc67..362178f 100755
--- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
+++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
@@ -360,6 +360,9 @@ raw_head()
 raw_body()
 {
prog="$(atf_get_srcdir)/h_raw"
+   # Begin FreeBSD
+   [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
+   # End FreeBSD
 
h_pass "$prog 9"
# Begin FreeBSD
diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
index 1649cc2..7bc8660 100644
--- a/lib/libc/tests/ssp/Makefile
+++ b/lib/libc/tests/ssp/Makefile
@@ -9,10 +9,7 @@ WARNS?=2
 
 CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
 .if ${COMPILER_TYPE} == "clang"
-# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
-.if ${COMPILER_VERSION} < 30500
 CFLAGS.h_raw+= -fsanitize=bounds
-.endif
 .elif ${COMPILER_TYPE} == "gcc"
 CFLAGS.h_raw+= --param ssp-buffer-size=1
 DPADD+=${LIBSSP}
@@ -29,7 +26,11 @@ PROGS+=  h_getcwd
 PROGS+=h_memcpy
 PROGS+=h_memmove
 PROGS+=h_memset
+# This testcase doesn't run properly when not compiled with -fsantize=bounds
+# with clang, which is currently contingent on a compiler_rt update
+.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30500
 PROGS+=h_raw
+.endif
 PROGS+=h_read
 PROGS+=h_readlink
 PROGS+=h_snprintf


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[Brooks Davis]

On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote:
> It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed:
> 
> 
> This works:
> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
> 
> This fails:
>  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
> 
> with:
> 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)

I've fixed the install problem.  I'm rather confused about why clang
would try to link with sanitizer libraries when building source.  That's
certainly not default behavior.

-- Brooks


signature.asc
Description: PGP signature

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[K. Macy]

On Monday, August 29, 2016, Volodymyr Kostyrko  wrote:

> Matthew Macy wrote:
>
>> It looks like there is something broken with the devel/llvm38 port or
>> external toolchain support has regressed:
>>
>>
>> This works:
>> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37
>> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
>>
>> This fails:
>>   make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38
>> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
>>
>> with:
>>
>> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclan
>> g_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory
>> clang-3.8: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>>
>
> I second this - I also faced it. I think this is not a problem with a
> ports but rather with a build as correspondent files can be found in
> /usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/.
> Looks like this files are compiled during build but taken from compilers's
> directory. Linking 'em to the target directory makes build succeed.


The point of using the external toolchain for me is to bypass building
clang in src. ~31 of the ~47 minutes in buildworld are spent compiling
pieces of llvm/clang. I'd much rather fix the ports than make buildworld
require additional work. For the moment I've disconnected the two pieces
that fail: svn and libc/tests. They don't really belong in base any more
than git and piglit do.


>
> --
> Sphinx of black quartz judge my vow.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[Dimitry Andric]

On 30 Aug 2016, at 05:12, Matthew Macy  wrote:
> 
> It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed:
> 
> 
> This works:
> make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s
> 
> This fails:
> make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s
> 
> with:
> 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory
> clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation)

Looks like the llvm38 port didn't build the libclang_rt libraries.  These are 
needed for the sanitizers, and so on.

The llvm37 port does have these:

% ls -l llvm37/lib/clang/3.7.1/lib/freebsd
total 4188
-rw-r--r--  1 root  wheel  2083354 2016-07-12 05:08:14 libclang_rt.asan-i386.a
-rwxr-xr-x  1 root  wheel   705264 2016-07-12 05:09:27 libclang_rt.asan-i386.so*
-rw-r--r--  1 root  wheel 1620 2016-07-12 05:08:06 
libclang_rt.asan-preinit-i386.a
-rw-r--r--  1 root  wheel35914 2016-07-12 05:08:12 
libclang_rt.asan_cxx-i386.a
-rw-r--r--  1 root  wheel   120524 2016-07-12 05:08:18 
libclang_rt.builtins-i386.a
-rw-r--r--  1 root  wheel33904 2016-07-12 05:08:19 
libclang_rt.profile-i386.a
-rw-r--r--  1 root  wheel   417872 2016-07-12 05:08:19 
libclang_rt.safestack-i386.a
-rw-r--r--  1 root  wheel   659270 2016-07-12 05:08:02 
libclang_rt.ubsan_standalone-i386.a
-rw-r--r--  1 root  wheel21234 2016-07-12 05:08:02 
libclang_rt.ubsan_standalone_cxx-i386.a

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: External toolchain support broken for devel/llvm38 but not devel/llvm37

[Volodymyr Kostyrko]

Matthew Macy wrote:

It looks like there is something broken with the devel/llvm38 port or external 
toolchain support has regressed:


This works:
make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s

This fails:
  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s

with:

/home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: 
/usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
 No such file: No such file or directory
clang-3.8: error: linker command failed with exit code 1 (use -v to see 
invocation)


I second this - I also faced it. I think this is not a problem with a 
ports but rather with a build as correspondent files can be found in 
/usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/. 
Looks like this files are compiled during build but taken from 
compilers's directory. Linking 'em to the target directory makes build 
succeed.


--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: External toolchain support

[Baptiste Daroussin]

On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote:
 
  On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote:
  
  Hi all,
  
  It is now possible to use an external toolchain to build the kernel and base
  (tested with gcc 4.9.1 and latest binutils)
  
  Of course a lot of work is needed to make it build cleanly (aka lots of 
  warning
  to fix).
  
  What have been tested so far:
  - sparc64 kernel + world
  - amd64 kernel + world
  - powerpc64 kernel + world
  
  mips cannot be tested because upstream gcc never heard of FreeBSD running on
  mips, and I did not receive any patches for mips.
 
 I have patches for 4.8 or so knocking around somewhere...

Seems like kan@ have patches for 4.9.1 and was able to build world with it!
(that is mips64)
 
[...snip...]
  
  also notes that for the kernel a lots of warnings are disabled in
  share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= 
  and
  fix the issue they are hidding!
 
 Cool. Please coordinate with me before removing the -Wno-error because they 
 vary by
 architecture.
 
Sure that was implied or build with all supported toolchains.

regards,
Bapt


pgpgvcrj4Oyt0.pgp
Description: PGP signature

Re: External toolchain support

[Warner Losh]

 On Dec 2, 2014, at 1:31 AM, Baptiste Daroussin b...@freebsd.org wrote:
 
 On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote:
 
 On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote:
 
 Hi all,
 
 It is now possible to use an external toolchain to build the kernel and base
 (tested with gcc 4.9.1 and latest binutils)
 
 Of course a lot of work is needed to make it build cleanly (aka lots of 
 warning
 to fix).
 
 What have been tested so far:
 - sparc64 kernel + world
 - amd64 kernel + world
 - powerpc64 kernel + world
 
 mips cannot be tested because upstream gcc never heard of FreeBSD running on
 mips, and I did not receive any patches for mips.
 
 I have patches for 4.8 or so knocking around somewhere...
 
 Seems like kan@ have patches for 4.9.1 and was able to build world with it!
 (that is mips64)

Cool. I also ported the arm patches as well. I thought I’d sent them to you, 
but it may have only been in the raw form. I also have patches for the extended 
printf checking for the kernel, though those are much more fragile than 
architecture support.

Warner


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: External toolchain support

[Baptiste Daroussin]

On Tue, Dec 02, 2014 at 09:23:00AM -0700, Warner Losh wrote:
 
  On Dec 2, 2014, at 1:31 AM, Baptiste Daroussin b...@freebsd.org wrote:
  
  On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote:
  
  On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote:
  
  Hi all,
  
  It is now possible to use an external toolchain to build the kernel and 
  base
  (tested with gcc 4.9.1 and latest binutils)
  
  Of course a lot of work is needed to make it build cleanly (aka lots of 
  warning
  to fix).
  
  What have been tested so far:
  - sparc64 kernel + world
  - amd64 kernel + world
  - powerpc64 kernel + world
  
  mips cannot be tested because upstream gcc never heard of FreeBSD running 
  on
  mips, and I did not receive any patches for mips.
  
  I have patches for 4.8 or so knocking around somewhere...
  
  Seems like kan@ have patches for 4.9.1 and was able to build world with it!
  (that is mips64)
 
 Cool. I also ported the arm patches as well. I thought I’d sent them to you, 
 but it may have only been in the raw form. I also have patches for the 
 extended printf checking for the kernel, though those are much more fragile 
 than architecture support.
 
The format extension I have them already, otherwise I won't be able to boot the
kernel (provided by kan as well).

See devel/powerp64-gcc/files/*

Regards,
Bapt


pgpscKUJgDowj.pgp
Description: PGP signature

Re: External toolchain support

[Lev Serebryakov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 29.11.2014 18:04, Baptiste Daroussin wrote:

 mips cannot be tested because upstream gcc never heard of FreeBSD
 running on mips, and I did not receive any patches for mips.
 I'm afraid, arm has same problem. I was need to patch arm-for-uC
toolchain to be able built it on ARM host, and this fix is very
cross-specific. As far as I know, gcc for freebsd-arm target needs
patches too, but different ones. At least to configure scripts  gcc
host-drivers.

- -- 
// Lev Serebryakov AKA Black Lion
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUfKyGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP8ZsP/jIWqU+9ACCR4/Rdf5A7SaGc
msCsofot9YrClKNJWPdjL0V2jMtKAURJVFf3OpRi6jXY9HJKzjIjHAoXDfwr97qP
9VyLgfvtNn+ffNuFuwUalwkiFcyzqvsADTHxFqFmCnhAAnjnHzn0CzushzKSRKYN
9yEhQphipCZ1DuP1cTE8z9/BOPAfXNjgjavfAYpnJARm+XZzPn2XG83rFnlLcZFo
UcByyuZznxfImH6hxoNsRVkdj5yvuGmzxQJQf+ilipiI3pDZk5/Q+ZWzWGap/gC/
0k2zWqyKO2O5pSNb8i8vsW2J+zg++BmMnO0VAt3pjxd4dqbrV5qk/g4oXiuxB2uX
8YnvbDJuLKzvI31GCrjOOa462yZlmoCBHRoqjUBZxeHh5QQSJyZjDc0ClRGbdfi/
FNLTx/jPhouxh1vEC1nV44FGS2v5Go9urKa1OhWYRrf+NyNlt7Ao5VutujgfQlvF
sLo663/Ja9W2MzLHmPanHMJcPl/Y7v9S7Mwh/EPCIe8Fd8VeYUPhOlT349Z7FnhT
e7Nu4zcnY82PJ4fU/yREHxZWsEwtRxx5vr1YrLClt8R7nx8ZXzq8A9JBLjqt/RfK
4BOe0D1t8zMARroiw9RaYFm8Md8nybWp+Q++ouME51jWWPgDxV9BbKaIx6Y4r+6V
RO63nTfg3A8uT/D60bIA
=aiOJ
-END PGP SIGNATURE-
___
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: External toolchain support

[Warner Losh]

 On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote:
 
 Hi all,
 
 It is now possible to use an external toolchain to build the kernel and base
 (tested with gcc 4.9.1 and latest binutils)
 
 Of course a lot of work is needed to make it build cleanly (aka lots of 
 warning
 to fix).
 
 What have been tested so far:
 - sparc64 kernel + world
 - amd64 kernel + world
 - powerpc64 kernel + world
 
 mips cannot be tested because upstream gcc never heard of FreeBSD running on
 mips, and I did not receive any patches for mips.

I have patches for 4.8 or so knocking around somewhere...

 for amd64, in the kernel two things had to be removed from the build:
 - aesni: (it request a header which is compiler specific and on recent gcc
 will end up including stdlib.h which gives errors because kernel version of 
 free
 and malloc are not compatible with the version defined in stdlib.h)
 - hptmv: I had to remove it from GENERIC and kernel building.
 
 The result is:
 
 $ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version
 
 kern.ostype: FreeBSD
 kern.osrelease: 11.0-CURRENT
 kern.osrevision: 199506
 kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64)
 
 so yes it boots and runs
 
 How to do you own testing:
 in the ports tree/packages (the amd64 version will appear in packages next 
 week)
 install:
 amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc
 
 if your source tree:
 make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel
 or
 make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel
 or
 make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel
 
 To build world:
 same operation with buildworld. Please note that for world you will need to 
 add
 define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk:
 s/--fatal-warnings/--no-fatal-warnings/)
 
 also notes that for the kernel a lots of warnings are disabled in
 share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and
 fix the issue they are hidding!

Cool. Please coordinate with me before removing the -Wno-error because they 
vary by
architecture.

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: External toolchain support

[Florian Smeets]

On 29/11/14 16:04, Baptiste Daroussin wrote:
 Hi all,
 
 It is now possible to use an external toolchain to build the kernel and base
 (tested with gcc 4.9.1 and latest binutils)
 

 make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel
 

I built a sparc64 kernel on amd64 using sparc64-xtoolchain-gcc
 and was able to boot it successfully.

$ uname -a
FreeBSD v240 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275267M: Sat Nov 29
22:23:38 CET root@storage:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC
sparc64
$ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version
kern.ostype: FreeBSD
kern.osrelease: 11.0-CURRENT
kern.osrevision: 199506
kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for
sparc64)

Florian



signature.asc
Description: OpenPGP digital signature

Re: External toolchain support

[Alfred Perlstein]

On 11/29/14, 7:04 AM, Baptiste Daroussin wrote:

Hi all,

It is now possible to use an external toolchain to build the kernel and base
(tested with gcc 4.9.1 and latest binutils)

Of course a lot of work is needed to make it build cleanly (aka lots of warning
to fix).

What have been tested so far:
- sparc64 kernel + world
- amd64 kernel + world
- powerpc64 kernel + world

mips cannot be tested because upstream gcc never heard of FreeBSD running on
mips, and I did not receive any patches for mips.

for amd64, in the kernel two things had to be removed from the build:
- aesni: (it request a header which is compiler specific and on recent gcc
will end up including stdlib.h which gives errors because kernel version of free
and malloc are not compatible with the version defined in stdlib.h)
- hptmv: I had to remove it from GENERIC and kernel building.

The result is:

$ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version

kern.ostype: FreeBSD
kern.osrelease: 11.0-CURRENT
kern.osrevision: 199506
kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64)

so yes it boots and runs

How to do you own testing:
in the ports tree/packages (the amd64 version will appear in packages next week)
install:
amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc

if your source tree:
make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel
or
make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel
or
make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel

To build world:
same operation with buildworld. Please note that for world you will need to add
define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk:
s/--fatal-warnings/--no-fatal-warnings/)

also notes that for the kernel a lots of warnings are disabled in
share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and
fix the issue they are hidding!

Best regards,
Bapt

This is amazing work, thank you Bapt!

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