From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8171C341056; Wed, 28 Jan 2026 22:02:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769637744; cv=none; b=OwBQRdr5htetUqkIHwD4ocTJ5C5HDj3biIQVe2wj8P9d2zvFA2qb9ifjKWLGrVj275y4piPbLTLf1wC72mnYfgFRVXrxISVRgsZJk4QC+wA+fr9TRJLEJlvBgtl+BCL3V6bSxQxyBVpll34kVIjDpsQiaq2vqz5Iw7a5Id46WDw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769637744; c=relaxed/simple; bh=p3Ov9GAWmc7miJdCYyGL4Sq5/XQCePT1md0p6UZP2ic=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XZqjohDHVQx/tFDKlxcl0U46Vsxm9Ss+O7eRcRMe64GVpI5x3IVRvM9BuALJT1Dx3YaMAQjIlhqx61CqPsJNOwVTOKBjEkYtkvFZ/DdZjAV0oF5QGHhWVhpY44hEbXkptVQg8V0of04GtlFNJNLzeC7hKpH7L6EcW3JoKKgjk1c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rO7foRxJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rO7foRxJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97859C4CEF1; Wed, 28 Jan 2026 22:02:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769637744; bh=p3Ov9GAWmc7miJdCYyGL4Sq5/XQCePT1md0p6UZP2ic=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rO7foRxJTLPHd7EFmeFADSjhcLf68oqo1bXtvO276v0tpiQsHqoDKl3Z0sZDYap7t oydPLH8RBKr2xqRKSq1kNRdbC/KxMHWJfc5Bs3h22MxttrBp1njG4p1Ihr2nJaetTs oP4/2edOoXnbb/r3/tCwp1HMuxeuzicVNtonlF3UXOzUQCFGOVjccp8hfclO2o8GGx uzxpMsVGixvOKTxDevSSkBn/1L4CuyWoQv2AJc7UAaqnPls0dpZ4hD7krNH9xEX7OJ aTCWZkvUNwAFBcGKjxj7bLUPm1oupEZ2pvi3AXEFzfIwHDnrcxTSmsJeD7CTEW1eoo 5xG1bDHuAJwIQ== Date: Wed, 28 Jan 2026 15:02:17 -0700 From: Nathan Chancellor To: Gary Guo Cc: Alexandre Courbot , Gary Guo , Miguel Ojeda , Boqun Feng , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Nicolas Schier , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Masahiro Yamada , Kees Cook , rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] kbuild: rust: use klint to provide CONFIG_FRAME_WARN Message-ID: <20260128220217.GA2129077@ax162> References: <20260127172330.1492107-1-gary@kernel.org> <20260127172330.1492107-3-gary@kernel.org> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jan 28, 2026 at 01:14:27AM +0000, Gary Guo wrote: > It might be possible to do more detailed analysis by checking what is using the > stack (e.g. perhaps recovery variable -> stack slots using DWARF if full > debuginfo is enabled, or find out the instruction that first touches the Yeah Nick wrote a Python script to use debug info to give a better idea of stack usage to help us debug these warnings from clang: https://github.com/ClangBuiltLinux/frame-larger-than It is rather hacky and feels like there are a number of corner cases where things don't look quite right but it is better than nothing. > specific stack location and map it back like that), but doing so is quite tricky > and the marginal benefit is less than pointing out there's an issue to be > investigated in the first place. Does Rust have the equivalent of '-Rpass-analysis' from clang? There was '-Rpass-analysis=stack-frame-layout' that was added in LLVM 16: https://github.com/llvm/llvm-project/commit/557a5bc336ffb9b03c53d4d13fd8f0bc9418ec96 I assume that could be used from Rust as well since it is in the LLVM backend? It does not necessarily show exactly where the stack usage comes from aside from variables and spills but still, some information (especially accurate information at this level) is better than nothing. Cheers, Nathan