| View previous topic :: View next topic |
| Author |
Message |
Duncan Mac Leod
Guru
Joined: 02 May 2004
Posts: 312
Location: Germany
|
 Posted: Mon May 31, 2021 1:56 pm Post subject: kernel 4.4.264 (x86) compile question |
 |
|
I am currently building kernel 4.4.264 gentoo-source for x86.
I noticed some strange compiler output in the log-files (I am sure that I've never seen such messages before)
Can I safely ignore them ??
./arch/x86/include/asm/bitops.h: Assembler messages:
./arch/x86/include/asm/bitops.h:139: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:96: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
./arch/x86/include/asm/bitops.h:96: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
./arch/x86/include/asm/bitops.h:96: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
./arch/x86/include/asm/bitops.h: Assembler messages:
./arch/x86/include/asm/bitops.h:122: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:122: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:122: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:122: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:122: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
CC drivers/hid/hid-debug.o
CC net/ipv4/tcp_output.o
CC drivers/hid/hidraw.o
CC drivers/hid/hid-generic.o
./arch/x86/include/asm/bitops.h: Assembler messages:
./arch/x86/include/asm/bitops.h:257: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:211: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
./arch/x86/include/asm/bitops.h:211: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
CC drivers/hid/hid-a4tech.o
./arch/x86/include/asm/bitops.h:96: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts'
./arch/x86/include/asm/bitops.h:139: Warning: no instruction mnemonic suffix given and no register operands; using default for `btr'
./arch/x86/include/asm/bitops.h:96: Warning: no instruction mnemonic suffix given and no register operands; using default for `bts' |
|
| Back to top |
|
 |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Mon May 31, 2021 10:19 pm Post subject: |
|
|
Looks like something fixed by 5.10.x alas, but it's due to gcc/binutils version too new for the kernel.
I would hope the default operation of binutils is to do what it's always done but now size is needed. Probably can ignore on little endian machines.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Duncan Mac Leod
Guru
Joined: 02 May 2004
Posts: 312
Location: Germany
|
| Posted: Tue Jun 01, 2021 11:48 am Post subject: |
|
|
| eccerr0r wrote: | Looks like something fixed by 5.10.x alas, but it's due to gcc/binutils version too new for the kernel.
I would hope the default operation of binutils is to do what it's always done but now size is needed. Probably can ignore on little endian machines. |
It's on my testing machine for personal use, so I let it pass: "kernel compiled successfully", reboot and IT WORKS (don't know what it really does under the hood).
But I also had two other machines with kernel 4.4.x (both are x64, not x86). Didn't try it yet - we'll see...
4.4.x is a LTS kernel supported til Feb '22, so it would be nice not to have all these compiler warnings during kernel compile (there were really a lot of these warnings).
Gentoo says, that we should always use the newest headers for glibc and a recent glibc/binutils/gcc version and this worked fine maintaining an older (still suppoprted) kernel all all over the years.
This is really the first time I ran into trouble compiling an 'old' but still supported kernel. |
|
| Back to top |
|
|
skiwarz
Apprentice
Joined: 23 Feb 2014
Posts: 263
|
| Posted: Tue Jun 01, 2021 12:57 pm Post subject: |
|
|
Purely out of curiosity, I'll ask:
Why are you on a 4.4 kernel instead of 5.X?
Maybe my head is buried in the sand, but you're the first person I've run into who does this, just wondering why? |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Tue Jun 01, 2021 2:00 pm Post subject: |
|
|
I know my Pentium-M laptop does not suspend/resume properly on 5.4.x and probably 5.10. Don't know why. Works fine on 4.4.x.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Jun 02, 2021 12:47 am Post subject: |
|
|
4.14. Why? Because I'm not aware of any reason I need 5.x I also don't care for "rapid fire" software releases that require a lot of work to evaluate. Jumping from 4 to 5 is just more work / time than I get back in value.
I had originally wanted to get a 5.0 config working, and, well now that's probably not worth it since 5.10 is LTS and they're calling 5.12.8 stable. I wonder when they're going to make a jump to 6. 4.14 has until Jan '24 and 4.19 until Dec '24 2024.12. So my next move is likely to be 4.19.
It is unfortunate there isn't a better "diff" option for upgrades.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Wed Jun 02, 2021 1:08 am Post subject: |
|
|
4.19 suspend/resume also did not work on my laptop, so there has been a lot of versions that it stopped working.
I really should do a bisect an figure out which version killed the suspend/resume...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1530
Location: South America
|
| Posted: Wed Jun 02, 2021 2:16 am Post subject: |
|
|
| Duncan Mac Leod wrote: | | 4.4.x is a LTS kernel supported til Feb '22, so it would be nice not to have all these compiler warnings during kernel compile (there were really a lot of these warnings). |
Likely related to this commit. I'm not familiar with Intel / AMD assembly so I don't know what it fixes exactly, the commit message just says that what the code did before was "bad practice". The latest version of every LTS series has these changes applied except... you guessed, 4.4.x. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Wed Jun 02, 2021 3:10 am Post subject: |
|
|
| Omitting the suffix allows the assembler to guess which width to use. I suspect that is considered bad practice because it is less predictable, and plausibly could change over time in cases where the other operands do not make it obvious to the assembler what is desired. The cited commit message says it changes the generated code on x86_64. Presumably, the new code is considered "right", and the old code happened to work. |
|
| Back to top |
|
|
skiwarz
Apprentice
Joined: 23 Feb 2014
Posts: 263
|
| Posted: Wed Jun 02, 2021 5:43 am Post subject: |
|
|
| pjp wrote: | 4.14. Why? Because I'm not aware of any reason I need 5.x I also don't care for "rapid fire" software releases that require a lot of work to evaluate. Jumping from 4 to 5 is just more work / time than I get back in value.
I had originally wanted to get a 5.0 config working, and, well now that's probably not worth it since 5.10 is LTS and they're calling 5.12.8 stable. I wonder when they're going to make a jump to 6. 4.14 has until Jan '24 and 4.19 until Dec '24 2024.12. So my next move is likely to be 4.19.
It is unfortunate there isn't a better "diff" option for upgrades. |
This brings up another question... I've always used "make olddefconfig" for my kernel upgrades, including when I went from 4.x to 5.x. I have never run into any major issues with it. Am I missing something? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Wed Jun 02, 2021 2:58 pm Post subject: |
|
|
olddefconfig takes the kernel developers' chosen "default" value for any new options. This has two potential downsides.
First, if a developer splits feature FOO into feature FOO and FOO-B, then marks -B as default N, then olddefconfig will set FOO-B=n, regardless of your setting for FOO. This could be bad for you if you had FOO=y for good reason. I once had a USB keyboard stop working because support for it moved to a new symbol, so the new kernel was built without support for that keyboard. Once I figured it out, rebuilding with FOO-B=y fixed it.
Second, if a developer adds a new symbol and sets default Y, then you will get it enabled, even if it is some obscure feature that you would choose n after reading the help text. This adds some small amount of bloat to your kernel. If you are the type of person who has aggressively removed all unused functionality, you might not like that you have now gained unused functionality. |
|
| Back to top |
|
|
|
Kernel & Hardware
