From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 A85DE33B94A for ; Wed, 17 Dec 2025 13:02:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765976529; cv=none; b=ZdL5A6XD0G6lxywTWs+heOF3Axu1aqdJDTzgtm9rj7DZj8Ts9UClIY+DP4fTtqUAdI+XRN8O+4FL2D++jIvu07QPV3coBI9zf4MaCcH5Gxp+fJ3KJPyauqHHiVV+6qh1ksokZJkVII3qpvbVMRlC/Tk9tSg8/DOhLlvu7AI11+Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765976529; c=relaxed/simple; bh=P7LwMXid3tpDY44yw/c1t3HPYB3Cr1J68bMcIvCey7U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BxhFwlYKHSNyP3hBU4VXeJIRa0ur6+uxwsYR2+CSL07ZsmMquT81+0VGGkE7kSmWggcyeuDQdbeGG3/mFtDr4eXyGilj+RhmKrDyxbD2SqvGf+subiBo2Y2FzDHfmQgaO8OSOUp2pWhwUVMlq57RGkKrCa/vPPnV/Yaqg05nMaQ= 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=tRjFZ8qy; arc=none smtp.client-ip=90.155.50.34 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="tRjFZ8qy" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=eQwLqOMJ5wj2Y3RQ1PgRiN05MmL9cHNT1UTp8Q3uG7Q=; b=tRjFZ8qyGeH9BQ56rz0FCTAu5U PeTBuJ/XS+NRZx0Ch53prZnx3+t2FgIAxv+fRkGSzFZfnuGpmh0d6kXqyglRm0ujuI9HuTYNtVSa8 iiHjONCguM9T/OyB9ykj0sSHn7CiRWOuRGu42lMIqSjwKlndJUVq142BrFouUk+h+DKB1dxqMr7oV 98/1HJUZZRTT5bGdkVsr67C8LavxXBOW90DQubTLBLjR1OlcPHeXgVjo9wSf55k49EoJ0rhSI5pq9 rCUvHGR2dMtxJ81D17W5iSrdR6+zL8yzjQ+FcbTNJVGR7FXXFbyjd+lDbj/sDpbmIERcfKrKJ8+cX GtTv5wtg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vVrAK-00000004jMh-3GEr; Wed, 17 Dec 2025 13:02:04 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 3C26B300DD3; Wed, 17 Dec 2025 14:02:04 +0100 (CET) Date: Wed, 17 Dec 2025 14:02:04 +0100 From: Peter Zijlstra To: Jean Delvare Cc: LKML , ubizjak@gmail.com Subject: Re: Build breakage caused by the use of UDB Message-ID: <20251217130204.GE3708021@noisy.programming.kicks-ass.net> References: <20251217124119.5832bba7@endymion> <20251217123536.GE3707891@noisy.programming.kicks-ass.net> <20251217124713.GD3708021@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=us-ascii Content-Disposition: inline In-Reply-To: <20251217124713.GD3708021@noisy.programming.kicks-ass.net> On Wed, Dec 17, 2025 at 01:47:13PM +0100, Peter Zijlstra wrote: > On Wed, Dec 17, 2025 at 01:35:36PM +0100, Peter Zijlstra wrote: > > On Wed, Dec 17, 2025 at 12:44:23PM +0100, Jean Delvare wrote: > > > Hi Peter, > > > > > > Kernel v6.18.1 doesn't build on x86_64 for me. The build failure is: > > > > > > make[1]: Entering directory '/home/khali/src/linux-6.18/drivers/net/wireless/realtek/rtlwifi/rtl8192c' > > > CC [M] main.o > > > CC [M] dm_common.o > > > CC [M] fw_common.o > > > CC [M] phy_common.o > > > CHECK main.c > > > fw_common.c: Assembler messages: > > > fw_common.c:416: Error: unknown pseudo-op: `.byte0x0f' > > > fw_common.c:391: Error: unknown pseudo-op: `.byte0x0f' > > > make[3]: *** [/home/khali/src/linux-6.18/scripts/Makefile.build:287: fw_common.o] Error 1 > > > make[3]: *** Waiting for unfinished jobs.... > > > CHECK dm_common.c > > > phy_common.c: Assembler messages: > > > phy_common.c:58: Error: unknown pseudo-op: `.byte0x0f' > > > phy_common.c:67: Error: unknown pseudo-op: `.byte0x0f' > > > ../wifi.h:3033: Error: unknown pseudo-op: `.byte0x0f' > > > ../wifi.h:3033: Error: unknown pseudo-op: `.byte0x0f' > > > phy_common.c:807: Error: unknown pseudo-op: `.byte0x0f' > > > phy_common.c:714: Error: unknown pseudo-op: `.byte0x0f' > > > make[3]: *** [/home/khali/src/linux-6.18/scripts/Makefile.build:287: phy_common.o] Error 1 > > > make[2]: *** [/home/khali/src/linux-6.18/Makefile:2010: .] Error 2 > > > make[1]: *** [/home/khali/src/linux-6.18/Makefile:248: __sub-make] Error 2 > > > make[1]: Leaving directory '/home/khali/src/linux-6.18/drivers/net/wireless/realtek/rtlwifi/rtl8192c' > > > make: *** [Makefile:248: __sub-make] Error 2 > > > > > > I bisected it down to: > > > > > > commit 85a2d4a890dce3cfc9c14aa91afc3dd7af8e3bf5 > > > Author: Peter Zijlstra > > > Date: Mon Sep 1 12:49:58 2025 +0200 > > > > > > x86,ibt: Use UDB instead of 0xEA > > > > > > Reverting this commit allows me to build v6.18.1. > > > > > > I must confess this is all way beyond me and I have no idea how this > > > change can cause such a build failure, but it does. If it matters, my > > > compiler is gcc 8.2.1. > > > > Well, that is somewhat unexpected. None of the build robots fingered > > this. Is there a particular .config I should try? > > > > I don't seem to have 8.2.1 at hand, but I'll try with 8.3.0. > > I had to (obviously) enable the RTL8192 bits, but then, yes. gcc-8 fails > to build this while gcc-10 doesn't seem to have any problems (for some > reason my random dev machine of the day doesn't seem to have gcc-9). > > Let me prod at this for a bit. But also, is there a good reason you're > using this stone-age compiler? :-) And yes, its our minimum supported, > so I suppose I should go fix, but other than build testing, you really > shoulnd't be using it. Yeah _ASM_BYTES(0x0f, 0x0b) doesn't seem to work right with gcc-8. It results in: .byte0x0f, 0x0b ; instead of the expected: .byte 0x0f, 0x0b ; What's worse, it only sometimes does this: $ grep ".byte[ ]*0x0f" defconfig-build/drivers/net/wireless/realtek/rtlwifi/base.s 1: .byte0x0f,0x0b ; 1: .byte 0x0f,0x0b ; W.T.F. and all that.