From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8C707EB64DC for ; Mon, 17 Jul 2023 05:02:16 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=Rl+mJVSU; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4R491L4njqz307V for ; Mon, 17 Jul 2023 15:02:14 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=Rl+mJVSU; dkim-atps=neutral Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4R490G0tNSz2xjw for ; Mon, 17 Jul 2023 15:01:18 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1689570072; bh=4+HGK2A3mSW6vOrfTG10sV4ewc0JcYSGbDt4jsrSWFY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Rl+mJVSUuNa5dRzkTFqUUPRAPEt6lFl8jwJ4c+Fu7UiYQi1KZfR0s8Eatskp2zzRh Yi7GJAQJZ9joUXeIo3XMyVhZzn/KtGTBiXQ7euus7+0yf2UqQLI8vJBCzQVcFZ55d0 oMHNHwoY84aGJncYVBsr3l0CO0vOtKQkBFkRrudCiwuTaL6Hs4RCcghFDXdiXu6Ay8 lb+GP4Fk1NHlMa4C24Misj3eKnPfVU6OvwA3+4j3woTnWRxDb9i1c6gJYlG/bMTSvf l2NM/+VpTtR7QdfNi7WN3cEHweWWjZt4KgbYxm5M2XJ+tocWA2ZafSJIZUiYIMoNun vKPtiilRiTBTA== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4R49076Jmrz4wZp; Mon, 17 Jul 2023 15:01:11 +1000 (AEST) From: Michael Ellerman To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [PATCH v5] Revert "powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto" In-Reply-To: References: <20230712134552.534955-1-mpe@ellerman.id.au> Date: Mon, 17 Jul 2023 15:01:07 +1000 Message-ID: <87a5vvjfn0.fsf@mail.lhotse> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "naveen.n.rao@linux.ibm.com" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe Leroy writes: > Le 12/07/2023 =C3=A0 15:45, Michael Ellerman a =C3=A9crit=C2=A0: >> From: Christophe Leroy >>=20 >> This partly reverts commit 1e688dd2a3d6759d416616ff07afc4bb836c4213. >>=20 >> That commit aimed at optimising the code around generation of >> WARN_ON/BUG_ON but this leads to a lot of dead code erroneously >> generated by GCC. >>=20 >> That dead code becomes a problem when we start using objtool validation >> because objtool will abort validation with a warning as soon as it >> detects unreachable code. This is because unreachable code might >> be the indication that objtool doesn't properly decode object text. >>=20 >> text data bss dec hex filename >> 9551585 3627834 224376 13403795 cc8693 vmlinux.before >> 9535281 3628358 224376 13388015 cc48ef vmlinux.after >>=20 >> Once this change is reverted, in a standard configuration (pmac32 + >> function tracer) the text is reduced by 16k which is around 1.7% >>=20 >> We already had problem with it when starting to use objtool on powerpc >> as a replacement for recordmcount, see commit 93e3f45a2631 ("powerpc: >> Fix __WARN_FLAGS() for use with Objtool") >>=20 >> There is also a problem with at least GCC 12, on ppc64_defconfig + >> CONFIG_CC_OPTIMIZE_FOR_SIZE=3Dy + CONFIG_DEBUG_SECTION_MISMATCH=3Dy : >>=20 >> LD .tmp_vmlinux.kallsyms1 >> powerpc64-linux-ld: net/ipv4/tcp_input.o:(__ex_table+0xc4): undefined= reference to `.L2136' >> make[2]: *** [scripts/Makefile.vmlinux:36: vmlinux] Error 1 >> make[1]: *** [/home/chleroy/linux-powerpc/Makefile:1238: vmlinux] Err= or 2 >>=20 >> Taking into account that other problems are encountered with that >> 'asm goto' in WARN_ON(), including build failures, keeping that >> change is not worth it allthough it is primarily a compiler bug. >>=20 >> Revert it for now. >>=20 >> mpe: Retain EMIT_WARN_ENTRY as a synonym for EMIT_BUG_ENTRY to reduce >> churn, as there are now nearly as many uses of EMIT_WARN_ENTRY as >> EMIT_BUG_ENTRY. > > In that case, should we keep __EMIT_BUG_ENTRY and also keep the check=20 > that makes sure nobody uses EMIT_BUG_ENTRY with BUGFLAG_WARNING ? I didn't think it was worth it, now that it's not a correctness issue. I think the better option would be to have EMIT_WARN_ENTRY add BUGFLAG_WARNING itself, rather than the caller having to pass it. cheers