linux-kernel - Re: objtool warning, branch, patch, and .config (GCC bug)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yo9lQxpj9U+fQTKH@tucnak>
Date:   Thu, 26 May 2022 13:32:19 +0200
From:   Jakub Jelinek <jakub@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>, Jan Hubicka <jh@...e.cz>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        linux-toolchains@...r.kernel.org
Subject: Re: objtool warning, branch, patch, and .config (GCC bug)

On Thu, May 26, 2022 at 11:41:24AM +0200, Peter Zijlstra wrote:
> On Thu, May 26, 2022 at 11:02:02AM +0200, Jakub Jelinek wrote:
> > On Thu, May 26, 2022 at 10:08:49AM +0200, Peter Zijlstra wrote:
> > > On Thu, May 26, 2022 at 10:03:13AM +0200, Peter Zijlstra wrote:
> > > 
> > > > Which is just bloody weird/broken if you ask me. What's worse, GCC-10
> > > > does the same. Only when I use GCC-11 do I get sensible code again:
> > > 
> > > Just to clarify, I can reproduce using:
> > > 
> > > gcc-9 (Debian 9.4.0-5) 9.4.0
> > > gcc-10 (Debian 10.3.0-15) 10.3.0
> > > 
> > > The good compiler is:
> > > 
> > > gcc-11 (Debian 11.3.0-1) 11.3.0
> > 
> > Such fallthrough into another function is typically the result
> > of __builtin_unreachable (), either explicit somewhere in the code,
> > or invoking undefined behavior somewhere and __builtin_unreachable ()
> > replacing the UB code.
> > I'd need preprocessed source + full gcc command line to tell more
> > (as long as it is not LTO, with LTO that isn't enough of course).
> 
>  $ make O=build/ CC=gcc-9 kernel/rcu/update.o V=1
> 
> gives the compile command as:
> 
>   gcc-9 -Wp,-MMD,kernel/rcu/.update.o.d -nostdinc -I../arch/x86/include -I./arch/x86/include/generated -I../include -I./include -I../arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I../include/uapi -I./include/generated/uapi -include ../include/linux/compiler-version.h -include ../include/linux/kconfig.h -include ../include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=../= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Werror -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -I ../kernel/rcu -I ./kernel/rcu    -DKBUILD_MODFILE='"kernel/rcu/update"' -DKBUILD_BASENAME='"update"' -DKBUILD_MODNAME='"update"' -D__KBUILD_MODNAME=kmod_update -c -o kernel/rcu/update.o ../kernel/rcu/update.c
> 
> I've attached the output of:
> 
>  $ make O=build/ CC=gcc-9 kernel/rcu/update.i

Filed https://gcc.gnu.org/PR105739 for this, the replacement
happens during inlining, so I've CCed Honza Hubicka who knows
that code best.

It is unlikely anything can be done about this for GCC 9,
because the final GCC 9.5 release is to be released tomorrow,
there is no chance of getting it fixed by then, especially
when it doesn't look like a recent regression.

	Jakub