Forums

Skip to content

Advanced search
  • Quick links
    • Unanswered topics
    • Active topics
    • Search
  • FAQ
  • Login
  • Register
  • Board index Assistance Kernel & Hardware
  • Search

objtool problems when compiling newest kernel

Kernel not recognizing your hardware? Problems with power management or PCMCIA? What hardware is compatible with Gentoo? See here. (Only for kernels supported by Gentoo.)
Post Reply
Advanced search
26 posts
  • 1
  • 2
  • Next
Author
Message
Saundersx
Apprentice
Apprentice
Posts: 294
Joined: Mon Apr 11, 2005 4:55 am

objtool problems when compiling newest kernel

  • Quote

Post by Saundersx » Tue Jan 23, 2018 9:34 pm

I compile my own kernel (as opposed to genkernel) and these started popping up recently (4.14.14-15)

Code: Select all

  CC      arch/x86/kernel/signal.o
arch/x86/kernel/signal.o: warning: objtool: do_signal()+0x78: return with modified stack frame
  CC      arch/x86/kernel/signal_compat.o
arch/x86/kernel/signal_compat.o: warning: objtool: copy_siginfo_to_user32()+0x21: sibling call from callable instruction with modified stack frame
  CC      arch/x86/kernel/traps.o
  CC      arch/x86/kernel/idt.o
arch/x86/kernel/idt.o: warning: objtool: idt_setup_from_table()+0xb3: stack state mismatch: reg1[3]=-1+0 reg2[3]=6-16
  CC      arch/x86/kernel/irq.o
  CC      arch/x86/kernel/irq_64.o
  CC      arch/x86/kernel/dumpstack_64.o
  CC      arch/x86/kernel/time.o
  CC      arch/x86/kernel/ioport.o
  CC      arch/x86/kernel/dumpstack.o
arch/x86/kernel/dumpstack.o: warning: objtool: __die()+0xa9: return with modified stack frame
  CC      arch/x86/kernel/nmi.o
  CC      arch/x86/kernel/ldt.o
/bin/sh: line 1: 21423 Segmentation fault      ./tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/ldt.o"
make[2]: *** [scripts/Makefile.build:321: arch/x86/kernel/ldt.o] Error 139
make[1]: *** [scripts/Makefile.build:579: arch/x86/kernel] Error 2
make: *** [Makefile:1028: arch/x86] Error 2
I have an Intel laptop and it happily compiles away without even so much as a warning. Reading into it I found this https://bugs.gentoo.org/642924 but after some testing it appears that march=native is not sneaking through. However comment #15 https://bugs.gentoo.org/642924#c15 implies this is an AMD issue. After further digging I found there are more objtool patches in the pipeline that haven't made their way into the kernel yet https://lkml.org/lkml/2018/1/23/450

However this install is certainly showing it's age, I use distcc and previously ccache/cross-compiling in the past so there may be some orphaned files floating around causing problems.

Simple question before I end up spending hours doing an unnecessary deep dive into my setup: Does anyone else with AMD (particularly piledriver) have these issues?
Top
krinn
Watchman
Watchman
User avatar
Posts: 7476
Joined: Fri May 02, 2003 6:14 am

  • Quote

Post by krinn » Tue Jan 23, 2018 9:45 pm

Code: Select all

binutils-config --linker ld.bfd
better?
Top
Saundersx
Apprentice
Apprentice
Posts: 294
Joined: Mon Apr 11, 2005 4:55 am

  • Quote

Post by Saundersx » Tue Jan 23, 2018 9:58 pm

Nope, same warnings/error.
Top
krinn
Watchman
Watchman
User avatar
Posts: 7476
Joined: Fri May 02, 2003 6:14 am

  • Quote

Post by krinn » Tue Jan 23, 2018 10:29 pm

then disable CONFIG_STACK_VALIDATION while waiting for the patch.
Top
Saundersx
Apprentice
Apprentice
Posts: 294
Joined: Mon Apr 11, 2005 4:55 am

  • Quote

Post by Saundersx » Tue Jan 23, 2018 10:33 pm

objtool crashing probably isn't an issue (I hope) so I just kept running make -j1 until it finished. One more thing failed

Code: Select all

/bin/sh: line 1: 23672 Segmentation fault      ./tools/objtool/objtool orc generate --no-fp "mm/memory.o"
Just going to run this kernel as is.
Top
Saundersx
Apprentice
Apprentice
Posts: 294
Joined: Mon Apr 11, 2005 4:55 am

  • Quote

Post by Saundersx » Tue Jan 23, 2018 10:34 pm

Just saw your post after mine, I'll try that next time if .16 comes out first.
Top
krinn
Watchman
Watchman
User avatar
Posts: 7476
Joined: Fri May 02, 2003 6:14 am

  • Quote

Post by krinn » Tue Jan 23, 2018 10:38 pm

the real answer now :)
commit f41b2d7ee791e845147a3e3cafb25493dca6870a
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date: Mon Jan 15 08:17:07 2018 -0600

objtool: Fix seg fault with gold linker

commit 2a0098d70640dda192a79966c14d449e7a34d675 upstream.

Objtool segfaults when the gold linker is used with
CONFIG_MODVERSIONS=y and CONFIG_UNWINDER_ORC=y.

With CONFIG_MODVERSIONS=y, the .o file gets passed to the linker before
being passed to objtool. The gold linker seems to strip unused ELF
symbols by default, which confuses objtool and causes the seg fault when
it's trying to generate ORC metadata.

Objtool should really be running immediately after GCC anyway, without a
linker call in between. Change the makefile ordering so that objtool is
called before the linker.
Wait for it, in case you want it already: https://cdn.kernel.org/pub/linux/kernel ... og-4.14.15
Top
Adarion
Tux's lil' helper
Tux's lil' helper
User avatar
Posts: 78
Joined: Mon Aug 22, 2005 9:17 pm

  • Quote

Post by Adarion » Fri Feb 02, 2018 1:23 pm

Strange. I just pulled in 4.14.16 and objtool still messes up totally.

stack state mismatch
can't decode instruction
return with modified stack frame
can't find jump dest instruction at
sibling call from callable instruction with modified stack frame

Error messages all over it.
In the end it segfaults. :(

objtool belongs to the kernel sources. Did the kernel devs not notice anything (in the linked changelog some fix was announced for 4.14.15 - but I'm with 4.14.16 here)? Can't be just my machine, right?
All regardless of gcc version (6.4.0-r1 or 7.3.0 (should have retpoline support)). So since 4.14.13 I was unable to compile ANY new kernel, which really sucks. I don't need KPTI (all AMD and/or ancient machines that aren't affected) but retpolines and stuff would be nice for a start. I do NOT want 4.4.xxx or 4.9.xx since those usually don't have recent amdgpu/radeon stack and the likes.

Is there anything as of early February that a Gentoo user can do about it?
stop tcpa, swpatents, corrupt politicians and other scary stuff
Top
Tyler_Durden
Apprentice
Apprentice
User avatar
Posts: 189
Joined: Tue Jul 27, 2004 10:01 am
Location: Germany

  • Quote

Post by Tyler_Durden » Fri Feb 02, 2018 3:45 pm

Adarion wrote:Strange...

Is there anything as of early February that a Gentoo user can do about it?
4.15 is not an option? switch to the bfd linker does not help?
Gentoo 17.1 x86_64
Intel Core i9-9900K
Asus MAXIMUS XI HERO
AMD Radeon 6800XT
64GB DDR4
Samsung SSD 970 EVO Plus 1TB
8x Seagate Archive (SATA-RAID 64TB)
Digital Devices Cine S2 V6.5 DVB Adapter
Top
Tony0945
Watchman
Watchman
Posts: 5127
Joined: Tue Jul 25, 2006 12:19 am
Location: Illinois, USA

  • Quote

Post by Tony0945 » Fri Feb 02, 2018 10:26 pm

related thread: Kernel won't build with CONFIG_MNATIVE, Kaveri
Top
assemblerhead
n00b
n00b
Posts: 36
Joined: Sat Jan 23, 2016 12:22 am
Location: TX,US

Thanks, a workaround that works. :D

  • Quote

Post by assemblerhead » Sat Feb 03, 2018 1:44 am

Bug in Question :
https://bugs.gentoo.org/645774

Switching the linker to ld.bfd and disabling "[ ] Compile-time stack metadata validation" got rid of the errors.

Also disabled :
[ ] Remove the kernel mapping in user mode
[ ] Avoid speculative indirect branches in kernel

The kernel compiled with AMD Piledriver set as CPU.

The 'Spectre / Meltdown' cure is a mess of conflicting patches it seems.

Thanks to the person who posted a link in/at the bug report.
Top
Tony0945
Watchman
Watchman
Posts: 5127
Joined: Tue Jul 25, 2006 12:19 am
Location: Illinois, USA

Re: Thanks, a workaround that works. :D

  • Quote

Post by Tony0945 » Sat Feb 03, 2018 11:01 am

assemblerhead wrote:disabling "[ ] Compile-time stack metadata validation" got rid of the errors.

Also disabled :
[ ] Remove the kernel mapping in user mode
[ ] Avoid speculative indirect branches in kernel
These are respectively:
CONFIG_STACK_VALIDATION
CONFIG_PAGE_TABLE_ISOLATION
CONFIG_RETPOLINE

STACK_VALIDATION can't be directly altered by make menuconfig.

Code: Select all

 Symbol: STACK_VALIDATION [=y]                                                                                                                                                         │
  │ Type  : boolean                                                                                                                                                                       │
  │ Prompt: Compile-time stack metadata validation                                                                                                                                        │
  │   Location:                                                                                                                                                                           │
  │     -> Kernel hacking                                                                                                                                                                 │
  │       -> Compile-time checks and compiler options                                                                                                                                     │
  │   Defined at lib/Kconfig.debug:369                                                                                                                                                    │
  │   Depends on: HAVE_STACK_VALIDATION [=y]                                                                                                                                              │
  │   Selected by: UNWINDER_ORC [=y] && <choice> && X86_64 [=y]  
Selecting any of the three unwinders doesn't change STACK_VALIDATION which is enabled by HAVE_STACK_VALIDATION

Code: Select all

Symbol: HAVE_STACK_VALIDATION [=y]                                                                                                                                                    │
  │ Type  : boolean                                                                                                                                                                       │
  │   Defined at arch/Kconfig:798                                                                                                                                                         │
  │   Selected by: X86 [=y] && X86_64 [=y]
How did you shut that off? Direct editing of .config? Or is CONFIG_X86 turned off in non-multilib profiles?

[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]
Top
philmiv
n00b
n00b
Posts: 8
Joined: Tue Jan 18, 2011 9:15 pm

  • Quote

Post by philmiv » Sat Feb 03, 2018 3:07 pm

I just managed to compile the 4.15 kernel without objtool segfaults / warnings by setting only:

Processor type and features -> Processor family -> Generic_x86_64 (previously it was AMD_Excavator)

I did that since I want to try the ORC unwinder, which depends on stack validation.
Top
assemblerhead
n00b
n00b
Posts: 36
Joined: Sat Jan 23, 2016 12:22 am
Location: TX,US

The requested info ...

  • Quote

Post by assemblerhead » Sat Feb 03, 2018 4:09 pm

@ Tony0945

Verified they are Disabled :
[ ] Compile-time stack metadata validation
[ ] Remove the kernel mapping in user mode
[ ] Avoid speculative indirect branches in kernel

Copied this direct from the .config :

Code: Select all

# Kernel Performance Events And Counters

CONFIG_HAVE_STACK_VALIDATION=y

Code: Select all

# Compile-time checks and compiler options

# CONFIG_STACK_VALIDATION is not set
No direct editing of the .config file was done.
The kernel compiled ... I am using it, no problems so far.

Also ...
I have sys-libs/binutils-libs USE="64-bit-bfd multitarget" installed as well.
Don't know if that makes a difference.
Top
Hu
Administrator
Administrator
Posts: 24403
Joined: Tue Mar 06, 2007 5:38 am

  • Quote

Post by Hu » Sat Feb 03, 2018 5:41 pm

Tony0945 wrote:STACK_VALIDATION can't be directly altered by make menuconfig.
That depends on other configuration options. With the right combination of other menuconfig choices, STACK_VALIDATION can be changed in menuconfig.
Tony0945 wrote:

Code: Select all

  │   Selected by: UNWINDER_ORC [=y] && <choice> && X86_64 [=y]  
Selecting any of the three unwinders doesn't change STACK_VALIDATION which is enabled by HAVE_STACK_VALIDATION
I get the same output, and that && <choice> && piece is confusing. However, you have the dependency relations a bit confused. You stated if HAVE_STACK_VALIDATION, then force STACK_VALIDATION. As I understand it, the relation is actually, if !HAVE_STACK_VALIDATION, then force !STACK_VALIDATION; if HAVE_STACK_VALIDATION, then permit (but do not force) STACK_VALIDATION.

If UNWINDER_ORC is enabled (and your output shows it is enabled for you), then that forces STACK_VALIDATION on. If you choose a different unwinder, you will be permitted to disable STACK_VALIDATION. I confirm that it does not automatically disable STACK_VALIDATION when a different unwinder is selected.
Tony0945 wrote:How did you shut that off? Direct editing of .config? Or is CONFIG_X86 turned off in non-multilib profiles?
Select an unwinder other than UNWINDER_ORC. Go to STACK_VALIDATION. Choose N.

CONFIG_X86 should be enabled for both x86 and amd64 profiles, both multilib and no-multilib (but at least on vanilla-sources, the kernel is wholly unaware of your profile; I think that applies to gentoo-sources also). The no-multilib profiles can be used without CONFIG_IA32_EMULATION, but CONFIG_X86 is a general flag indicating you are on an Intel/AMD/etc. family, rather than ARM, SPARC, etc.
Top
assemblerhead
n00b
n00b
Posts: 36
Joined: Sat Jan 23, 2016 12:22 am
Location: TX,US

  • Quote

Post by assemblerhead » Sat Feb 03, 2018 9:49 pm

Just thought of this ... should have explained this in an earlier posting.
I modify the vendor support for CPUs in 'menuconfig'

A good number of the config choices change when you enable expert config in 'make menuconfig'

Enable expert config in 'make menuconfig'

Code: Select all

[*] Configure standard kernel features (expert users)  --->
Then modify this :

Code: Select all

[*] Supported processor vendors  --->   

--- Supported processor vendors
[ ]   Support Intel processors
[*]   Support AMD processors
[ ]   Support Centaur processors
I was surprised at the difference that made. 'dmesg' output looks a lot different.
A lot easier to understand where the problems are.
Top
krinn
Watchman
Watchman
User avatar
Posts: 7476
Joined: Fri May 02, 2003 6:14 am

Re: Thanks, a workaround that works. :D

  • Quote

Post by krinn » Sat Feb 03, 2018 11:19 pm

assemblerhead wrote:Thanks to the person who posted a link in/at the bug report.
You're welcome ;)
Top
Tony0945
Watchman
Watchman
Posts: 5127
Joined: Tue Jul 25, 2006 12:19 am
Location: Illinois, USA

  • Quote

Post by Tony0945 » Sat Feb 03, 2018 11:49 pm

philmiv wrote: Processor type and features -> Processor family -> Generic_x86_64 (previously it was AMD_Excavator)

I did that since I want to try the ORC unwinder, which depends on stack validation.
My Kaveri should have built with excavtor also but Bulldozer (bdver1) was as high as it would go.
I went the route you did, starting with generic and ending at bulldozer. Same with Bristol Ridge.
Should beat generic.
Top
Tony0945
Watchman
Watchman
Posts: 5127
Joined: Tue Jul 25, 2006 12:19 am
Location: Illinois, USA

  • Quote

Post by Tony0945 » Sun Feb 04, 2018 12:53 am

Hu wrote:If UNWINDER_ORC is enabled (and your output shows it is enabled for you), then that forces STACK_VALIDATION on. If you choose a different unwinder, you will be permitted to disable STACK_VALIDATION. I confirm that it does not automatically disable STACK_VALIDATION when a different unwinder is selected.
Tony0945 wrote:How did you shut that off? Direct editing of .config? Or is CONFIG_X86 turned off in non-multilib profiles?
Select an unwinder other than UNWINDER_ORC. Go to STACK_VALIDATION.
That works. Thanks, again, Hu. Once I did that, CONFIG_MNATIVE worked fine.

It is a bit of a hack because the stack validation is a good thing. Detailed explanation is found in /usr/src/linux/tools/objtool/Documentation/stack-validation.txt
I see what the objtool talk is all about and it seems likely that recent patches have neglected the macro in places that bdver1 and below don't reach.

EDIT: Surprisingly, the altered kernel seems to boot noticeably slower. That is, OpenRC is slower. The messages used to race across the screen too fast to read on the Bristol Ridge.
Maybe gcc-6.4.0 's Bristol Ridge optimizations aren't as good as the BDVER1 optimizations.
Top
Adarion
Tux's lil' helper
Tux's lil' helper
User avatar
Posts: 78
Joined: Mon Aug 22, 2005 9:17 pm

  • Quote

Post by Adarion » Thu Feb 22, 2018 4:42 pm

Tyler_Durden wrote:
Adarion wrote:Strange...
Is there anything as of early February that a Gentoo user can do about it?
4.15 is not an option? switch to the bfd linker does not help?
Yes, but usually I wait for a few point releases until the worst fallout of a new major kernel release has settled. ;)



Selecting anything else than ORC unwinder did not help (frame pointer unwinder). By the way, this is also located in kernel hacking and ORC seems to be the (recommended) default.
Also in terms of any further GCC settings, linker settings and so on, I usually stay with the defaults (unless I think I know what I am doing, and I do not have that feeling here ;) ).

Today I compiled successfully on my Kabini system - what actually seemed to help (gcc 6.4.0-r1) was to switch CPU type in the Kernel config to amd64 generic (x86_64) - no specific CPU type. Voila! It compiled, I booted it and I had all the fancy new stuff in. Still only moderate Spectre countermeasures since I wasn't using gcc 7.3.x for that, but okay.

At the very moment my AMD FX-6300 is also compiling gentoo-sources:4.15.4 with the same generic x86_64 setting and NOT complaining (and seems regardless of other settings so far)! (Please stay so!)
Moments ago I tried with "gcc autodetect native CPU" setting in CPU type and it failed again with countless error messages littered along the compilation process.

So for me the kernel config
Processor type and features -> Processor family -> Generic-x86-64
aka CONFIG_GENERIC_CPU [=y]
"solved" the issue. Of course I am not entirely happy to run something that might be using no optimizations, but well, it's a start.

I'll give it a try with gcc 7.3.x later.
stop tcpa, swpatents, corrupt politicians and other scary stuff
Top
Tony0945
Watchman
Watchman
Posts: 5127
Joined: Tue Jul 25, 2006 12:19 am
Location: Illinois, USA

  • Quote

Post by Tony0945 » Thu Feb 22, 2018 7:18 pm

Adarion wrote:Selecting anything else than ORC unwinder did not help (frame pointer unwinder). By the way, this is also located in kernel hacking and ORC seems to be the (recommended) default. .
What's needed is to remove unwinding entirely. Which is a little higher in the menu.
https://cateee.net/lkddb/web-lkddb/STAC ... ATION.html
Top
BGazotti
n00b
n00b
Posts: 1
Joined: Fri Dec 10, 2021 1:32 pm
Location: Brazil

  • Quote

Post by BGazotti » Fri Dec 10, 2021 1:37 pm

I'm somewhat sorry for reviving this thread, but just wanted to let y'all know that this issue is back in 5.15. Using -march=native or -march=bdver2 on my FX-6300 leads to tons of objtool warnings and an unbootable kernel. I'm compiling it again with -march=bdver1 and so far there's no warnings being produced, so I'm optimistic about that. Curiously, 5.14 didn't have that problem. I'll also go to kernel.org and report a bug there.
Top
sam_
Developer
Developer
User avatar
Posts: 2817
Joined: Fri Aug 14, 2020 12:33 am

  • Quote

Post by sam_ » Fri Dec 10, 2021 5:11 pm

BGazotti wrote:I'm somewhat sorry for reviving this thread, but just wanted to let y'all know that this issue is back in 5.15. Using -march=native or -march=bdver2 on my FX-6300 leads to tons of objtool warnings and an unbootable kernel. I'm compiling it again with -march=bdver1 and so far there's no warnings being produced, so I'm optimistic about that. Curiously, 5.14 didn't have that problem. I'll also go to kernel.org and report a bug there.
Could you update this post with a link to the bug when you report it?

Thanks!
Top
Goverp
Advocate
Advocate
User avatar
Posts: 2404
Joined: Wed Mar 07, 2007 6:41 pm

  • Quote

Post by Goverp » Fri Dec 10, 2021 6:46 pm

Interesting. I had the problem on my bdver4 laptop some time back, and cured it with "mcpu=bdver2 mtune=bdver4"! Works fine on kernel 5.15.7 ...
Greybeard
Top
Goverp
Advocate
Advocate
User avatar
Posts: 2404
Joined: Wed Mar 07, 2007 6:41 pm

  • Quote

Post by Goverp » Fri Oct 06, 2023 1:25 pm

It's back again!

I built kernel 6.5.5 with -march=bdver4, and couldn't boot the result. I tried again and only just noticed an objtool message whizzing past. Retry with

Code: Select all

make clean
make > make.log
made it much easier to see a screenful of stderr messages.

Following BGazotti's post, I've just compiled 6.5.6 (which showed the same problem) with

Code: Select all

-march=bdver1 -mtune=bdver4
and that cures the messages. Haven't tried booting with it yet.

Note I can't say if the problem was or wasn't there earlier; due to finger trouble I'd been mistakenly using "-mtune=bdver4" instead of "-march=bdver4" for some time before 6.5.5.

<edit>Yup, that boots OK.
Greybeard
Top
Post Reply

26 posts
  • 1
  • 2
  • Next

Return to “Kernel & Hardware”

Jump to
  • Assistance
  • ↳   News & Announcements
  • ↳   Frequently Asked Questions
  • ↳   Installing Gentoo
  • ↳   Multimedia
  • ↳   Desktop Environments
  • ↳   Networking & Security
  • ↳   Kernel & Hardware
  • ↳   Portage & Programming
  • ↳   Gamers & Players
  • ↳   Other Things Gentoo
  • ↳   Unsupported Software
  • Discussion & Documentation
  • ↳   Documentation, Tips & Tricks
  • ↳   Gentoo Chat
  • ↳   Gentoo Forums Feedback
  • ↳   Duplicate Threads
  • International Gentoo Users
  • ↳   中文 (Chinese)
  • ↳   Dutch
  • ↳   Finnish
  • ↳   French
  • ↳   Deutsches Forum (German)
  • ↳   Diskussionsforum
  • ↳   Deutsche Dokumentation
  • ↳   Greek
  • ↳   Forum italiano (Italian)
  • ↳   Forum di discussione italiano
  • ↳   Risorse italiane (documentazione e tools)
  • ↳   Polskie forum (Polish)
  • ↳   Instalacja i sprzęt
  • ↳   Polish OTW
  • ↳   Portuguese
  • ↳   Documentação, Ferramentas e Dicas
  • ↳   Russian
  • ↳   Scandinavian
  • ↳   Spanish
  • ↳   Other Languages
  • Architectures & Platforms
  • ↳   Gentoo on ARM
  • ↳   Gentoo on PPC
  • ↳   Gentoo on Sparc
  • ↳   Gentoo on Alternative Architectures
  • ↳   Gentoo on AMD64
  • ↳   Gentoo for Mac OS X (Portage for Mac OS X)
  • Board index
  • All times are UTC
  • Delete cookies

© 2001–2026 Gentoo Foundation, Inc.

Powered by phpBB® Forum Software © phpBB Limited

Privacy Policy

 

 

magic