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 EECE82F12AE; Fri, 6 Mar 2026 22:45:26 +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=1772837127; cv=none; b=MxLgBp0sqnSf6chdl0ssnobu2TjbHjnjFqTr9bYgfrENgXCJSuZFIQcEgNcE27CR5Ra3wxgrWl6pCnDSiNgiKu+KujYM6g2q0lF+ySOZV20EbE4z+1tp2J3jSACyR4UscK9Fu17smkTfLRCRLPVXMAsmoTfPQ2Wv2FXT9Iej8Ew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772837127; c=relaxed/simple; bh=dNOTZvU0FlC/ztZAG6jbBsB2dYRaK/F+Ss9rz9BLcJw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kg1Rl6CONl0b0e/F9/1wqDSrsISJiRv62FyB8NXmwsdhPchN+n7pEnHworFT0hQgzVcruc8AKRXfEGSazNijlMUmGAFhiKnvjVgNCRq5OrWwN1teEOWzNCX7Q31pTDfPNwhnrGtAzmrcQ0DWgLiqXtci0ODUFFZtx14IsCussmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G7rmqkmY; 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="G7rmqkmY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D26CC4CEF7; Fri, 6 Mar 2026 22:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772837126; bh=dNOTZvU0FlC/ztZAG6jbBsB2dYRaK/F+Ss9rz9BLcJw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=G7rmqkmYzPAAuBwDV/3HhLULIgdLnT1wjhffepT0VLV2ePkjVdyD9iohYCrGa2HGl Nw5MGI7d08ll44xQJa13q7tWA22KgnC0BrhXbFHu9+sMLmn+Mq++SsaaRybEQY4UpT CNHQJ7YJu5uhdesrh0gdlwlI1g8N0tZhPtbYOBX1qxMPBjCmZl8vZM1OtqkXNLL6Io 9sz3NhuszGQgEvh/JRxh4UaYjfXXIMmd9AE/f9m6M7i4MR0mcbg6i+2EYgSz+q4y/T T8VM7vp41OAGIQ7AbQyeHYyyQFHEPO6GQ6LcdYvUIeEtrXQ9GioUcM+KsPWIj6PBUr 7h+zz1Gj0FH5w== Date: Fri, 6 Mar 2026 15:45:22 -0700 From: Nathan Chancellor To: Yonghong Song Cc: Josh Poimboeuf , linux-kbuild@vger.kernel.org, live-patching@vger.kernel.org, kernel-team@fb.com, Nicolas Schier , Song Liu Subject: Re: [PATCH kbuild] kbuild: Allow to reduce the number of suffixes for clang thin-lto build Message-ID: <20260306224522.GA2746259@ax162> References: <20260306034325.3605301-1-yonghong.song@linux.dev> Precedence: bulk X-Mailing-List: live-patching@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 Fri, Mar 06, 2026 at 02:12:44PM -0800, Yonghong Song wrote: > So you mean we do not need a new config. Should just check clang and > clang versionn like below? > > diff --git a/Makefile b/Makefile > index e944c6e71e81..9bd3990024c5 100644 > --- a/Makefile > +++ b/Makefile > @@ -1034,6 +1034,11 @@ endif > ifdef CONFIG_LTO_CLANG > ifdef CONFIG_LTO_CLANG_THIN > CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit > +ifdef CONFIG_CC_IS_CLANG > +ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 230000; echo $$?),0) This is the same as ifeq ($(call clang-min-version,230000),y) That being said, could we not just do a dynamic check so that it always works when these flags are supported? > +KBUILD_LDFLAGS += --lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false) > +endif > +endif > else > CC_FLAGS_LTO := -flto > endif > > I think this should work. In rare case, renaming the function should > solve the problem. I agree with Josh that having this be the default behavior with the workarounds that we have available to us to avoid problems from it is worth it. Thanks for chasing this after the discussions at LPC. Cheers, Nathan