From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 7DDA22882D7 for ; Wed, 19 Nov 2025 08:44:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763541881; cv=none; b=bLI4XHM87czcxCWN69a2VlEpRgjrShMgM1YLaNV41B/0S1YEZ1mfQ32pbycP5kKIvWmuilPR5h3JKmXeNYV5j+Fir/PhjU5zzle/gNOy83x7Ct5yz7qgTIWJyb15+lI70pq2gEIYNNJ3xR0svqsJSoAk07j5lLkgUqg1Hn3vOpc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763541881; c=relaxed/simple; bh=GLGQ946eQ7sMchvIdLOsxHXERgmW9dtKKy3RngYPps4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e184SKqb3tJyu3p5CTvrmTAAIzzc9+HlYS+fHpiGlm640nglDMW8exPVniKDYbx5kuBXireuk6Iucd6Z1xOjw4aeaABip7IdUaEY9nEFXAPZuecCwh1b0KkoLjkHOuPAWkEJgy87zVnKEtB8XMdBTtKc2PcblnYKgIypu9klr+g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=KCfurjzo; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KCfurjzo" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=fveAJX7mJCRxFugdVUIRntk/kNOS2+X7DXAyEg2Ee6Q=; b=KCfurjzo00bz8YEYjCIyB6e2Wo SxSZovDtVfiJaugEqbs/d9Ra1xnBzGAsqdPSGgpHC68ir7fvZQTEX1UNRTwU3+yanM+BJkCX1NR1H IVh06grV/ZO/HJs5Dyw4g70qDCq95qO2XFusjhmcMYpsNW0W/ZLtsR3yTE7AHe54vfyHTOHzB34ZB ghbKpdZdoBUoUXaD836zOITzO2/LOZdzFdHYOoFNVMK34xRWH1Zt8MUD/AtMovqs+uZzpCvhGaA3M dvzArcx9JbboonNst83F1IKnS+3pAABwk3Ge/G4YKhlK7HjwAV1IqP3iLlL6IoyZkMQr0bMkhOgnt PSWLWhgg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vLcwB-0000000BePo-0VRX; Wed, 19 Nov 2025 07:49:11 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4EE4A3003C4; Wed, 19 Nov 2025 09:44:35 +0100 (CET) Date: Wed, 19 Nov 2025 09:44:35 +0100 From: Peter Zijlstra To: Jiri Slaby Cc: Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , kernel test robot Subject: Re: [PATCH] serial: icom: Fix namespace collision and startup() section placement with -ffunction-sections Message-ID: <20251119084435.GJ4068168@noisy.programming.kicks-ass.net> References: <45630ac97b19b8d3194763fe7f54bb3b498f3728.1763533593.git.jpoimboe@kernel.org> <23f084ab-7b1a-485e-be1e-e639906fd5b3@kernel.org> <20251119084315.GI4067720@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251119084315.GI4067720@noisy.programming.kicks-ass.net> On Wed, Nov 19, 2025 at 09:43:15AM +0100, Peter Zijlstra wrote: > On Wed, Nov 19, 2025 at 07:58:05AM +0100, Jiri Slaby wrote: > > On 19. 11. 25, 7:27, Josh Poimboeuf wrote: > > > When compiling the kernel with -ffunction-sections (e.g., for LTO, > > > livepatch, dead code elimination, AutoFDO, or Propeller), the startup() > > > function gets compiled into the .text.startup section. In some cases it > > > can even be cloned into .text.startup.constprop.0 or > > > .text.startup.isra.0. > > > > > > However, the .text.startup and .text.startup.* section names are already > > > reserved for use by the compiler for __attribute__((constructor)) code. > > > > > > This naming conflict causes the vmlinux linker script to wrongly place > > > startup() function code in .init.text, which gets freed during boot. > > > > This sounds rather error-prone. What are the patterns supposed to match > > actually? Can't *those* real victims™ be renamed to something less common > > instead? > > Yeah, this is a terrible mess. The problem is that when linking objects > build with and without -ffunction-sections you can no longer uniquely > identify what's what :-( > > As long as its consistently one or the other it works, but if you mix > them constructors and normal function like this get mixed up. > > In another thread I've suggested this might be a toolchain bug, but even > if they agree and fix it, we still stuck with the old compilers. And I'm > not sure the toolchain people are agreeing there's anything wrong here > -- the argument is that you shouldn't be mixing this or somesuch. > > Anyway, objtool has a warning for this, so new occurrences should be > flagged before they get introduced. But yes, we need to make the tree > clean first. Also, that objtool warning only really works architectures that have objtool on, other archs can indeed silently create fail :-(