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 7DAC032ED30 for ; Wed, 17 Dec 2025 13:34:35 +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=1765978477; cv=none; b=uA4sjRNQFJiZ5FI7gHqWVJzD6gFxRNobEMaG12h6CB7TP3xrpzmWdnY7zLtZYNAhN7Yp4S/GsoqgXznXfHDVjT8+3mppDPn8QLw7qXf+gtb1qmH3yFjUdlUc5ziOrWZtMDXz/3Vn1UVyHhhrOcFe7R8pdxfbm7mXVojqYJQ6hKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765978477; c=relaxed/simple; bh=A1msq5oPf9SMDmFj1gc9CEGLP+2RMk6/plmBcpYyUGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oCLCtuIepqvCqynbJnxb1xJrXHBeicwlCQBxN7C6R9AKAhLAorN6jlkfRe7QvimavTDKg5XMrv4inD/tCaJZDZKFWBsfyamJeb6ucGEgITZrO/5iIl2rDC9f6g97XpIXe+MWKM7KzKCE4U2eYz2aCh+wGPiRBrGJfLHIqGgClzk= 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=XMIi/GCl; 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="XMIi/GCl" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=iCCbnfh+W+0EHTwxbCb25LWzaa/+nvUgKTGuQIGl0lE=; b=XMIi/GClQtMbUPP205bIMV3yqU lsvcb8kNHfheMW4rJIrliBr4zv4zDw1Zphv3BWpHKCb/3JGXUbdGCJKD5SHA4+BqC4zxyRYWjfAvU FsQUNLR4s25cZnLqnPiKgQVnHYZFCaO8SiBzryPDqGsjGOu/BZd8GVn8jVjcjf+gBlzhysBv9ZPSt ikEJIgynQqZyt/ZBsTMhMmHrPtLeBiG98OPpgVrRHpd//gtFkRzpMxNKzhR+/vdbB9e1y7JayJ5P0 MFbv97DUWNBARH+CrKBGV3bVhVphk+VeRfZme0Ixwh8dc98JcNtfFL9Og1tDlD7PoepUvXSAkVXJY RwmqJ2uQ==; 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 1vVqoH-00000006rIS-2pDu; Wed, 17 Dec 2025 12:39:17 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 97A853005E0; Wed, 17 Dec 2025 14:34:31 +0100 (CET) Date: Wed, 17 Dec 2025 14:34:31 +0100 From: Peter Zijlstra To: Jean Delvare Cc: LKML , ubizjak@gmail.com, Josh Poimboeuf , ardb@kernel.org, Linus Torvalds , x86@kernel.org Subject: Re: Build breakage caused by the use of UDB Message-ID: <20251217133431.GF3708021@noisy.programming.kicks-ass.net> References: <20251217124119.5832bba7@endymion> <20251217123536.GE3707891@noisy.programming.kicks-ass.net> <20251217124713.GD3708021@noisy.programming.kicks-ass.net> <20251217130204.GE3708021@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: <20251217130204.GE3708021@noisy.programming.kicks-ass.net> On Wed, Dec 17, 2025 at 02:02:04PM +0100, Peter Zijlstra wrote: > 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. The below seems to 'cure' things, but I'm not sure this is the best option. Expanded Cc for more suggestions. --- diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h index 0e8c611bc9e2..8f6c834a6164 100644 --- a/arch/x86/include/asm/asm.h +++ b/arch/x86/include/asm/asm.h @@ -9,15 +9,16 @@ # define __ASM_FORM_RAW(x, ...) x,## __VA_ARGS__ # define __ASM_FORM_COMMA(x, ...) x,## __VA_ARGS__, # define __ASM_REGPFX % +# define _ASM_BYTES(...) .byte __VA_ARGS__ ; #else #include # define __ASM_FORM(x, ...) " " __stringify(x,##__VA_ARGS__) " " # define __ASM_FORM_RAW(x, ...) __stringify(x,##__VA_ARGS__) # define __ASM_FORM_COMMA(x, ...) " " __stringify(x,##__VA_ARGS__) "," # define __ASM_REGPFX %% -#endif +# define _ASM_BYTES(...) " .byte " __stringify(__VA_ARGS__) " ;" -#define _ASM_BYTES(x, ...) __ASM_FORM(.byte x,##__VA_ARGS__ ;) +#endif #ifndef __x86_64__ /* 32 bit */