kern/173337: clang kernel cross-builds ignore CPUTYPE?= and always generate native tuned code

Howard Goldstein hg at
Sat Nov 3 20:40:01 UTC 2012

>Number:         173337
>Category:       kern
>Synopsis:       clang kernel cross-builds ignore CPUTYPE?= and always generate native tuned code
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 03 20:40:00 UTC 2012
>Originator:     Howard Goldstein
Oct 30 13:45:20 pickle kernel: FreeBSD 9.1-PRERELEASE #13: Thu Oct 25 22:29:56 E
DT 2012
Oct 30 13:45:20 pickle kernel: hg at i3
Oct 30 13:45:20 pickle kernel: CPU: Intel(R) Core(TM)2 Duo CPU     E6750  @ 2.66
GHz (2667.76-MHz 686-class CPU)
Oct 30 13:45:20 pickle kernel: Origin = "GenuineIntel"  Id = 0x6fb  Family = 0x6
  Model = 0xf  Stepping = 11
Oct 30 13:45:20 pickle kernel: Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MC

Kernel compiled on a system id'd as a core2 a/k/a nocona in i386 mode  (above)
and stock clang of 9.1 prerelease 13:

 pickle:~$ clang -v
 FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
 Target: i386-unknown-freebsd9.0
 Thread model: posix

for a i386 for a pentium4 both i386 with these set in make.conf


The resulting kernel seems to actually be built for the host 
as if -march=native were set, ignoring CPUTYPE?=pentium4

This is almost surely the same problem reported on -stable by
Volodymyr Kostyrko c.kworr on Wed Oct 24 07:57:26 UTC 2012


Build a kernel with clang on a host that is, for lack of a better expression
"stronger" than your handy, "lesser" target.  For ex., a core2 host targetting
a pentium-m.

Now install emulators/wine or emulator/wine-devel, built however you
like. The wine process handles its own trapping which makes this very
difficult to identify (for me, anyway) as a kernel issue:

err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x622...

and wine opens a black window and hangs up.

>From gdb it's a bit more verbose and yields a map file error.

This is probably impossible to reproduce without a separate target system
real or virtual that doesn't support the instruction set of the build host.



Revert to stock gcc4.2 for crossbuilding 9.1 kernels destined for 
a specific CPUTYPE that doesn't  match the host

This PR may belong in conf or ports instead of kern, please recategorize
 Release:       FreeBSD 9.1-PRERELEASE i386

More information about the freebsd-bugs mailing list