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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 99A23ECAAD3 for ; Wed, 14 Sep 2022 10:21:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229728AbiINKVR (ORCPT ); Wed, 14 Sep 2022 06:21:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229714AbiINKVO (ORCPT ); Wed, 14 Sep 2022 06:21:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C19FD7A537; Wed, 14 Sep 2022 03:21:11 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 10B8B61B7A; Wed, 14 Sep 2022 10:21:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8A2FC433C1; Wed, 14 Sep 2022 10:21:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663150870; bh=DiPQNoNQNG+LQNzk/iOQ5X8mk924KHwwG68nSONOT+c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LLIIKfyfTOvDZbH9wZaRqn8c0Jveo+TQ6Zt7JqKiPzkEsMLIQ2+OrSOPk+A75ttv9 cdYSrFuCTthS8RzN8Fv301CuEb8gxC/23zBONTWkIngBDkRj7kzEKYY+2WLrXUExAx PB05AkMjWJbeZwNBT6PLMz3GsjFf5jQ9L0QBC4fsSAFVVO2vF9bL+DlurkFyPXHYJj ExNEJTXC06DKdUMf1iLprTPmyOLqTvi1MjJX8basjkokHqeUbpyq3d2+r6WAKnnLav k6tHWhkuTxHDL3h18VQp1RJwgEhAOREqBPIheMRG2gg2U6A8bvuQw8pkSRGvyp8jy+ LusWJ4Sfx2AIA== Date: Wed, 14 Sep 2022 11:21:00 +0100 From: Josh Poimboeuf To: Segher Boessenkool Cc: Mark Rutland , Peter Zijlstra , linuxppc-dev@lists.ozlabs.org, Chen Zhongjin , x86@kernel.org, Nick Desaulniers , linux-kernel@vger.kernel.org, Mark Brown , Sathvika Vasireddy , linux-toolchains@vger.kernel.org, Indu Bhagat , live-patching@vger.kernel.org, Miroslav Benes , Will Deacon , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, "Jose E. Marchesi" , Michael Matz Subject: Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Message-ID: <20220914102100.thl5ad35plvazark@treble> References: <20220909180704.jwwed4zhwvin7uyi@treble> <20220912113114.GV25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220912113114.GV25951@gate.crashing.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 12, 2022 at 06:31:14AM -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > > 2) Noreturn functions: > > > > There's no reliable way to determine which functions are designated > > by the compiler to be noreturn (either explictly via function > > attribute, or implicitly via a static function which is a wrapper > > around a noreturn function.) > > Or just a function that does not return for any other reason. > > The compiler makes no difference between functions that have the > attribute and functions that do not. There are good reasons to not > have the attribute on functions that do in fact not return. The > not-returningness of the function may be just an implementation > accident, something you do not want part of the API, so it *should* not > have that attribute; or you may want the callers to a function to not be > optimised according to this knowledge (you cannot *prevent* that, the > compiler can figure it out it other ways, but still) for any other > reason. Yes, many static functions that are wrappers around noreturn functions have this "implicit noreturn" property. I agree we would need to know about those functions (or, as Michael suggested, their call sites) as well. > > This information is needed because the > > code after the call to such a function is optimized out as > > unreachable and objtool has no way of knowing that. > > Since June we (GCC) have -funreachable-traps. This creates a trap insn > wherever control flow would otherwise go into limbo. Ah, that's interesting, though I'm not sure if we'd be able to distinguish between "call doesn't return" traps and other traps or reasons for UD2. -- Josh 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 BC004C6FA86 for ; Wed, 14 Sep 2022 10:21:56 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MSGbQ6TKsz3c6n for ; Wed, 14 Sep 2022 20:21:54 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=LLIIKfyf; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4601:e00::1; helo=ams.source.kernel.org; envelope-from=jpoimboe@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=LLIIKfyf; dkim-atps=neutral Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4MSGZh3Zbbz2xKX for ; Wed, 14 Sep 2022 20:21:16 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B6C4AB81979; Wed, 14 Sep 2022 10:21:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8A2FC433C1; Wed, 14 Sep 2022 10:21:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663150870; bh=DiPQNoNQNG+LQNzk/iOQ5X8mk924KHwwG68nSONOT+c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LLIIKfyfTOvDZbH9wZaRqn8c0Jveo+TQ6Zt7JqKiPzkEsMLIQ2+OrSOPk+A75ttv9 cdYSrFuCTthS8RzN8Fv301CuEb8gxC/23zBONTWkIngBDkRj7kzEKYY+2WLrXUExAx PB05AkMjWJbeZwNBT6PLMz3GsjFf5jQ9L0QBC4fsSAFVVO2vF9bL+DlurkFyPXHYJj ExNEJTXC06DKdUMf1iLprTPmyOLqTvi1MjJX8basjkokHqeUbpyq3d2+r6WAKnnLav k6tHWhkuTxHDL3h18VQp1RJwgEhAOREqBPIheMRG2gg2U6A8bvuQw8pkSRGvyp8jy+ LusWJ4Sfx2AIA== Date: Wed, 14 Sep 2022 11:21:00 +0100 From: Josh Poimboeuf To: Segher Boessenkool Subject: Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Message-ID: <20220914102100.thl5ad35plvazark@treble> References: <20220909180704.jwwed4zhwvin7uyi@treble> <20220912113114.GV25951@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220912113114.GV25951@gate.crashing.org> 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: Mark Rutland , Michael Matz , Will Deacon , Peter Zijlstra , linuxppc-dev@lists.ozlabs.org, x86@kernel.org, Nick Desaulniers , linux-kernel@vger.kernel.org, Mark Brown , Sathvika Vasireddy , linux-toolchains@vger.kernel.org, Indu Bhagat , live-patching@vger.kernel.org, Miroslav Benes , Chen Zhongjin , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, "Jose E. Marchesi" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Sep 12, 2022 at 06:31:14AM -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > > 2) Noreturn functions: > > > > There's no reliable way to determine which functions are designated > > by the compiler to be noreturn (either explictly via function > > attribute, or implicitly via a static function which is a wrapper > > around a noreturn function.) > > Or just a function that does not return for any other reason. > > The compiler makes no difference between functions that have the > attribute and functions that do not. There are good reasons to not > have the attribute on functions that do in fact not return. The > not-returningness of the function may be just an implementation > accident, something you do not want part of the API, so it *should* not > have that attribute; or you may want the callers to a function to not be > optimised according to this knowledge (you cannot *prevent* that, the > compiler can figure it out it other ways, but still) for any other > reason. Yes, many static functions that are wrappers around noreturn functions have this "implicit noreturn" property. I agree we would need to know about those functions (or, as Michael suggested, their call sites) as well. > > This information is needed because the > > code after the call to such a function is optimized out as > > unreachable and objtool has no way of knowing that. > > Since June we (GCC) have -funreachable-traps. This creates a trap insn > wherever control flow would otherwise go into limbo. Ah, that's interesting, though I'm not sure if we'd be able to distinguish between "call doesn't return" traps and other traps or reasons for UD2. -- Josh 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 38D13ECAAD3 for ; Wed, 14 Sep 2022 10:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3QWGa9s3NQk3dm73JtpA72oYKF7keZnzdaZL9d1yPyw=; b=SNhFowuPmT0rtc U9nVP89hsx2WWZC/u8DhA2IEY6Rt0hnBXSuH6tRaNX45c5RmzIt2MIQbvxNhQ/AoIy1OKggiBQU9J apds069JMgacjTEa9C6pfl0OBD5gWWuWvenS1UkPHnKfC0vbRHKcXuUugj7Te8sejcfa5p2pIJsKK oCaHbiWqe6a9jiQKXuMlUPSVBsKCw2e52isBsJY9DyMiMRKW3jBk/ZJtGT3h0ETMFyx0o1BKxp/eP BbhbfFEcJ1mQ1auEoErupzh6cTyNMe6FjSdlf3QonOoE1jVq7oJ3M3kiNW7g6+vHUlTsgKq5CQ6xS OUJpXNoo2mLMeaiBO2XQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYPW8-00F1EJ-KR; Wed, 14 Sep 2022 10:21:16 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYPW5-00F19z-Fk for linux-arm-kernel@lists.infradead.org; Wed, 14 Sep 2022 10:21:15 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B6C4AB81979; Wed, 14 Sep 2022 10:21:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8A2FC433C1; Wed, 14 Sep 2022 10:21:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663150870; bh=DiPQNoNQNG+LQNzk/iOQ5X8mk924KHwwG68nSONOT+c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LLIIKfyfTOvDZbH9wZaRqn8c0Jveo+TQ6Zt7JqKiPzkEsMLIQ2+OrSOPk+A75ttv9 cdYSrFuCTthS8RzN8Fv301CuEb8gxC/23zBONTWkIngBDkRj7kzEKYY+2WLrXUExAx PB05AkMjWJbeZwNBT6PLMz3GsjFf5jQ9L0QBC4fsSAFVVO2vF9bL+DlurkFyPXHYJj ExNEJTXC06DKdUMf1iLprTPmyOLqTvi1MjJX8basjkokHqeUbpyq3d2+r6WAKnnLav k6tHWhkuTxHDL3h18VQp1RJwgEhAOREqBPIheMRG2gg2U6A8bvuQw8pkSRGvyp8jy+ LusWJ4Sfx2AIA== Date: Wed, 14 Sep 2022 11:21:00 +0100 From: Josh Poimboeuf To: Segher Boessenkool Cc: Mark Rutland , Peter Zijlstra , linuxppc-dev@lists.ozlabs.org, Chen Zhongjin , x86@kernel.org, Nick Desaulniers , linux-kernel@vger.kernel.org, Mark Brown , Sathvika Vasireddy , linux-toolchains@vger.kernel.org, Indu Bhagat , live-patching@vger.kernel.org, Miroslav Benes , Will Deacon , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, "Jose E. Marchesi" , Michael Matz Subject: Re: [RFC] Objtool toolchain proposal: -fannotate-{jump-table,noreturn} Message-ID: <20220914102100.thl5ad35plvazark@treble> References: <20220909180704.jwwed4zhwvin7uyi@treble> <20220912113114.GV25951@gate.crashing.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220912113114.GV25951@gate.crashing.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220914_032113_701250_DC3AA15E X-CRM114-Status: GOOD ( 26.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Sep 12, 2022 at 06:31:14AM -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote: > > 2) Noreturn functions: > > > > There's no reliable way to determine which functions are designated > > by the compiler to be noreturn (either explictly via function > > attribute, or implicitly via a static function which is a wrapper > > around a noreturn function.) > > Or just a function that does not return for any other reason. > > The compiler makes no difference between functions that have the > attribute and functions that do not. There are good reasons to not > have the attribute on functions that do in fact not return. The > not-returningness of the function may be just an implementation > accident, something you do not want part of the API, so it *should* not > have that attribute; or you may want the callers to a function to not be > optimised according to this knowledge (you cannot *prevent* that, the > compiler can figure it out it other ways, but still) for any other > reason. Yes, many static functions that are wrappers around noreturn functions have this "implicit noreturn" property. I agree we would need to know about those functions (or, as Michael suggested, their call sites) as well. > > This information is needed because the > > code after the call to such a function is optimized out as > > unreachable and objtool has no way of knowing that. > > Since June we (GCC) have -funreachable-traps. This creates a trap insn > wherever control flow would otherwise go into limbo. Ah, that's interesting, though I'm not sure if we'd be able to distinguish between "call doesn't return" traps and other traps or reasons for UD2. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel