Kernel won't build with CONFIG_MNATIVE, Kaveri

krinn · Watchman Joined: 02 May 2003 Posts: 7470

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

Tony0945 · Posted: Tue Jan 30, 2018 5:35 pm Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

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 · Posted: Tue Jan 30, 2018 6:31 pm Post subject:

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!

NeddySeagoon · Posted: Tue Jan 30, 2018 6:34 pm Post subject:

Tony0945,

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

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Tony0945 · Posted: Tue Jan 30, 2018 7:26 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

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 · Posted: Wed Jan 31, 2018 1:15 pm Post subject:

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 · Moderator Joined: 06 Mar 2007 Posts: 21633

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.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

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).