# Kernel won't build with  CONFIG_MNATIVE, Kaveri

## Tony0945

```
 # uname -a

Linux gentoo.MsHome 4.14.15-gentoo #1 SMP Mon Jan 29 16:55:26 CST 2018 x86_64 AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G AuthenticAMD GNU/Linux

```

 Builds with Generic-x86-64, k8, k8 with SSE, k10. Previous kernels built with CONFIG_MNATIVE.

I'm finding the same on my Bristol Ridge system, except NO kernel builds with MNATIVE.  

```
arch/x86/entry/vsyscall/.tmp_vsyscall_64.o: warning: objtool: emulate_vsyscall()+0x70: stack state mismatch: cfa1=7+56 cfa2=7+48

arch/x86/ia32/.tmp_ia32_aout.o: warning: objtool: aout_core_dump()+0x368: return with modified stack frame
```

Bristol Ridge adds errors like "can't find jmp target".

```
 # equery w gcc

/usr/portage/sys-devel/gcc/gcc-6.4.0-r1.ebuild

```

----------

## krinn

objtool is bugging you?

https://forums.gentoo.org/viewtopic-t-1075862.html

----------

## Tony0945

 *krinn wrote:*   

> objtool is bugging you?
> 
> https://forums.gentoo.org/viewtopic-t-1075862.html

 

Thanks, krinn.

binutils-config --linker ld.bfd  -- didn't work

-j1   instead of -j5  --  didn't work

 CONFIG_STACK_VALIDATION   --- no such option found

switch CONFIG_UNWINDER_ORC to CONFIG_UNWINDER_GUESS   ----  ran really slow but much farther then failed with:

```
/bin/sh: line 1:   733 Segmentation fault      ./tools/objtool/objtool check --no-fp "mm/.tmp_memory.o"

```

Sounds like the problem but I have two questions:

1) Why only with -march=native?

                      Note that -march=native works on a Phenom II but not Kaveri or Bristol Ridge

2) I am building 4.15.15 from 4.14.15 so is the fix being applied to a revision of 4.14.15 or a later kernel?

----------

## krinn

it's a new tool (ok for me, i recently switch to kernel 4.x and i really cannot remember seen it before), which is a dirty explain for the result: that thing is buggy

----------

## Tony0945

Well it looks like my options are to mask >4.14.13 (4.15.0 has the same problem) or continue building with march=k10 which is better than generic.

EDIT:

HELLO!  All versions of binutils in the tree are masked!

```
 # eix -e binutils

[I] sys-devel/binutils

     Available versions:

     (2.25.1) [M]2.25.1-r1

     (2.26.1) [M]2.26.1

     (2.27) [M](~)2.27-r1

     (2.28.1) {M}2.28.1

     (2.29.1) [m]2.29.1-r1

     (2.30) [m](~)2.30

     (git)  [m]**9999

       {(+)cxx doc multitarget (+)nls static-libs test vanilla zlib}

     Installed versions:  2.28.1(2.28.1)(09:39:38 PM 12/21/2017)(cxx -multitarget -nls -static-libs -test -vanilla)

     Homepage:            https://sourceware.org/binutils/

     Description:         Tools necessary to build programs

```

----------

## NeddySeagoon

Tony0945,

You need 4.15 and 4.16 (not out yet) for the security fixes.

----------

## Tony0945

 *NeddySeagoon wrote:*   

> Tony0945,
> 
> You need 4.15 and 4.16 (not out yet) for the security fixes.

 

I usually run the latest gentoo-sources but don't understand why MNATIVE fails but MK10 works. Especially when MNATIVE works on the older kernels.

I unmasked binutils-2.30 and tried it, no go.

Building binutils-2.29-r1 now  and will try it.  EDIT: No effect.

I saw a bug report asking that GOLD be a useflag but it's the usual UNCONFIRMED.

Maybe I should go back to profile 13.0 and unwind the gcc change from 17.0?

----------

## Hu

MK10, MNATIVE, and similar options change the opcodes the compiler is allowed to use and change the architecture for which the code is optimized.  If I were to guess from what has been posted, MNATIVE enables the compiler to use opcodes and/or code layout that confuses objtool, but MK10 causes the compiler to use opcodes and a layout that objtool handles successfully.  If so, then it might be sensitive to the code being compiled.  Older kernels may not have included the specific C code that, when compiled with MNATIVE, produces object code that confuses objtool.

Unless your system is routinely CPU bound in kernel mode, you have probably already spent more time writing about this (minutes) than you could make back by getting it working (a few seconds per day if you're lucky).  You probably spend <5% of CPU time running in kernel mode (as opposed to sleeping or running in user mode).  You might make back 1% of kernel time by getting this to work, so <.05% faster. If it were me, I would use the suboptimal MK10 for now and revisit it on a later kernel release.

----------

## Tony0945

Setting the processor type to bdver1 also works. bdver2,bdver3 and bdver cause the compilation to fail for kaveri. However, a series of benchmarks posted on phoronix for kaver1 (but for gcc 4.9 not 6.4.0) shows miniscule differences for the various bdverX (as suggested by Hu). However, any bdverX is a notable improvement over older archs. I don't know if the bg is in gcc (unlikely, all other packages build with march=native) or the kernel, but Hu is right, trying to get the last 1% isn't worth it. Going to bdver1 may be worth as much as 20% depending on the applicaion. Next, looking at Bristol ridge to see if it works with bdver1.

EDIT:  Bristol Ridge also compiles with bdver1 but nothing higher. Non-kernel code builds fine with bdver4 or native for both processors.

----------

## Hu

I didn't realize that such a large improvement was available by using bdver instead of an older architecture.  Perhaps it would be worth the time spent fixing this.  Regardless, if you want to pursue this for general interest, please go ahead.  I only wanted to state that the practical value of fixing it is low for a single desktop (versus fixing this for a fleet of hundreds of machines).  The personal satisfaction value could be quite high even for a single desktop.  :Smile: 

----------

## Ant P.

The big difference from -march=bdver1 comes from enabling AVX, which makes GCC generate code for that instead of all the minor variations of SSE. AVX registers are a superset of SSE ones in size and number; it's the same difference as going from MMX to SSE (or i686 to amd64).

----------

