Re: "Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

* Marek Zarychta wrote:


* Warner Losh wrote:



I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do
these sorts of things. CPUTYPE is known to only work on native builds



Maybe you should try to build using different make.conf(5) files for
each build? It can be improved WITH_META_MODE=YES enabled in
src-env.conf (requires loading filemon(4) first) and two differnt object


Thanks for the hint. While experimenting with it, I found the -- 
somewhat obvious, in hind sight -- solution.


The source of the trouble is the build system's installed 
/usr/lib/libc.a, which the /usr/src/tmp binaries are linked against, as 
well as some few other things.


The fix is to have a world on the build system that is built without any 
CPUTYPE setting, so that the compiler only uses the original amd64 
instruction set; that goes up to SSE2. An actual "distribution" 
buildworld can then use any CPUTYPE that the intended target supports.


A workaround, at least for upgrading from 11.1 to stable/11, is to 
remove the /usr/obj/usr/src/tmp directory entirely, so that 
installkernel and installworld use the tools on the target system. It 
worked for me, but is probably not entirely reliable.


I still think there is an argument to be made for avoiding this kind of 
potential breakage in "near cross" builds, but it is probably not worth 
the extra effort during buildworld (rebuild, or at least relink, 
/usr/src/tmp etc. against the freshly made libc.a).


The "few other things" above are, by the way:

- usr.bin/mkesdb_static
- usr.bin/mkcsmapper_static
- rescue

The first two are not installworld'ed, so I wonder why they are where 
they are, and the last one is a cruel, cruel thing to do.


Thanks for your help!

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

Re: "Cross" building for same architecture, different CPUTYPE

[Marek Zarychta]

On Sun, Mar 04, 2018 at 07:32:09PM +0100, Christian Ullrich wrote:
> * Warner Losh wrote:
> 
> > On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric  > > wrote:
> > 
> > Again, this depends on how exactly you are overriding CPUTYPE.
> > 
> > I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do 
> > these sorts of things. CPUTYPE is known to only work on native builds 
> 
> Doesn't work either, sorry:
> 
> [chul@build /usr/obj/slm/usr/src/tmp/legacy/usr/bin]$ CCACHE_DISABLE=yes 
> MAKEOBJDIRPREFIX=/usr/obj/slm make TARGET_CPUTYPE=slm -j4 buildworld 
> buildkernel
> ...
> [chul@build /usr/obj/slm/usr/src/tmp/legacy/usr/bin]$ objdump -d install 
> | fgrep '(bad)' | wc -l
>  8345
> 
> This objdump (in base, "GNU objdump 2.17.50 [FreeBSD] 2007-07-03") does 
> not understand AVX, and most of the (bad)s are c4 and c5 prefixes, aka AVX.
> 
> For /usr/obj/slm/usr/src/lib/libc/libc.so.7 I get a lot of (bad), too, 
> but these seem to be instructions that the chip actually has, only the 
> old objdump does not know them.
> 
> The same happens with the TARGET_CPUTYPE in make.conf , and also if I 
> spell it "silvermont". bsd.cpu.mk turns "slm" into "silvermont", but 
> somehow it ends up as "-march=slm" on the command line again. gcc's docs 
> say "-march=silvermont", and clang is apparently notorious for not 
> providing any useful detail on what architecture variants it supports.
> 
> Should I try make release? I'm really interesting in something that will 
> bring down build time, because buildworld/buildkernel on the Atom takes 
> 24 hours without ccache and at least 8 with.

Maybe you should try to build using different make.conf(5) files for
each build? It can be improved WITH_META_MODE=YES enabled in
src-env.conf (requires loading filemon(4) first) and two differnt object
directories mounted in /usr/obj with nullfs(5). I do such crossbuilds
for some time compiling kernel and world for core2 on admfam10. Full
build of STABLE takes usually < 10 minutes on 8 years old Phenom II.

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

Re: "Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

* Warner Losh wrote:

On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric > wrote:


Again, this depends on how exactly you are overriding CPUTYPE.

I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do 
these sorts of things. CPUTYPE is known to only work on native builds 


Doesn't work either, sorry:

[chul@build /usr/obj/slm/usr/src/tmp/legacy/usr/bin]$ CCACHE_DISABLE=yes 
MAKEOBJDIRPREFIX=/usr/obj/slm make TARGET_CPUTYPE=slm -j4 buildworld 
buildkernel

...
[chul@build /usr/obj/slm/usr/src/tmp/legacy/usr/bin]$ objdump -d install 
| fgrep '(bad)' | wc -l

8345

This objdump (in base, "GNU objdump 2.17.50 [FreeBSD] 2007-07-03") does 
not understand AVX, and most of the (bad)s are c4 and c5 prefixes, aka AVX.


For /usr/obj/slm/usr/src/lib/libc/libc.so.7 I get a lot of (bad), too, 
but these seem to be instructions that the chip actually has, only the 
old objdump does not know them.


The same happens with the TARGET_CPUTYPE in make.conf , and also if I 
spell it "silvermont". bsd.cpu.mk turns "slm" into "silvermont", but 
somehow it ends up as "-march=slm" on the command line again. gcc's docs 
say "-march=silvermont", and clang is apparently notorious for not 
providing any useful detail on what architecture variants it supports.


Should I try make release? I'm really interesting in something that will 
bring down build time, because buildworld/buildkernel on the Atom takes 
24 hours without ccache and at least 8 with.


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

Re: "Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

* Dimitry Andric wrote:


On 4 Mar 2018, at 18:29, Christian Ullrich  wrote:



I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here.


Actually, that *is* relevant for the stages after bootstrap-tools,
build-tools and cross-tools.  E.g. 4.x and later.

Again, this depends on how exactly you are overriding CPUTYPE.


Thank you for the explanation, Dimitry. As I wrote, I have the host's 
native CPUTYPE in make.conf (CPUTYPE?=core-avx2) and the target on the 
command line (make CPUTYPE=slm buildworld buildkernel).


Since my previous e-mail, I actually had the bright idea of removing 
.../tmp/legacy/usr/bin/install, and that let the installkernel succeed.


My previous assumption that the remainder of the build obeyed the 
override must have been wrong, though, because installworld failed in 
strip for /lib/libc.so.7, and after that, nothing worked anymore.


Perhaps I should get a non-x86(_64) build host and really do a full 
cross build ...


Thanks again,

--
Christian

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

Re: "Cross" building for same architecture, different CPUTYPE

[Warner Losh]

On Sun, Mar 4, 2018 at 10:43 AM, Dimitry Andric  wrote:

> Again, this depends on how exactly you are overriding CPUTYPE.


I'd suggest *NOT* setting CPUTYPE and instead using TARGET_CPUTYPE to do
these sorts of things. CPUTYPE is known to only work on native builds and
is tricky to do in this scenario just so. It might work for 'near cross'
builds, or it might not. TARGET_CPUTYPE overrides CPUTYPE that might be set
in weird places and generally works a lot better. You don't need to set
TARGET or TARGET_ARCH to do this, but it would work if you did that also.

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

Re: "Cross" building for same architecture, different CPUTYPE

[Dimitry Andric]

On 4 Mar 2018, at 18:29, Christian Ullrich  wrote:
> 
> I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel Atom 
> CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build machine. 
> That works fine, but make installkernel on the Atom box fails with a SIGILL 
> (signal 4) in the "install" command (sorry, no log or screenshot).
> 
> As far as I can tell, this is because installkernel uses the install from 
> ...obj.../tmp/legacy/usr/bin, which is built for the host. Disassembling the 
> binary shows that it uses AVX opcodes. The "main" part of the build output 
> correctly respects the CPUTYPE override.

How are you overriding?  As far as I know, the bootstrap-tools are built
using NO_CPU_CFLAGS, which disables any cpu-specific CFLAGS.  However,
this does not work in two cases:

1) If you assign CPUTYPE with = instead of ?= (in make.conf or src.conf)
2) If you set -march= flags in CFLAGS directly

With 1), if you specify CPUTYPE= as a variable directly on the make
command line, it will effectively disable NO_CPU_CFLAGS.


> I suppose I'm doing something wrong here, but what? It must be possible to 
> build for a different CPU of the same family, right? I even tried running a 
> cross build (TARGET=amd64 TARGET_ARCH=amd64), but since the build host _is_ 
> amd64, the Makefiles laughed at me and only did the normal build.
> 
> The command that did not work was:
> 
> MAKEOBJDIRPREFIX=/usr/obj/slm make CPUTYPE=slm buildworld buildkernel
> 
> I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here.

Actually, that *is* relevant for the stages after bootstrap-tools,
build-tools and cross-tools.  E.g. 4.x and later.

Again, this depends on how exactly you are overriding CPUTYPE.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

"Cross" building for same architecture, different CPUTYPE

[Christian Ullrich]

Hello,

I'm trying to buildworld/buildkernel of stable/11 r330373 for an Intel 
Atom CPU (CPUTYPE=slm) on a (slightly faster, CPUTYPE=core-avx2) build 
machine. That works fine, but make installkernel on the Atom box fails 
with a SIGILL (signal 4) in the "install" command (sorry, no log or 
screenshot).


As far as I can tell, this is because installkernel uses the install 
from ...obj.../tmp/legacy/usr/bin, which is built for the host. 
Disassembling the binary shows that it uses AVX opcodes. The "main" part 
of the build output correctly respects the CPUTYPE override.


I suppose I'm doing something wrong here, but what? It must be possible 
to build for a different CPU of the same family, right? I even tried 
running a cross build (TARGET=amd64 TARGET_ARCH=amd64), but since the 
build host _is_ amd64, the Makefiles laughed at me and only did the 
normal build.


The command that did not work was:

MAKEOBJDIRPREFIX=/usr/obj/slm make CPUTYPE=slm buildworld buildkernel

I have CPUTYPE?=core-avx2 in make.conf, but that should be irrelevant here.

Thanks for any hints.

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