Build breakage caused by the use of UDB

Build breakage caused by the use of UDB

[Jean Delvare]

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.

-- 
Jean Delvare
SUSE L3 Support

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

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.

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

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.

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

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.

Re: Build breakage caused by the use of UDB

[Jean Delvare]

Hi Peter,

On Wed, 17 Dec 2025 13:47:13 +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:  
> > > 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).

As an additional data point, clang 17.0.6 builds the kernel just fine
for me.

> 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.

Actually the default C compiler on my openSUSE Leap 15.6 system is even
gcc 7, I had to manually install gcc 8 and use CC= because gcc 7 is no
longer supported for upstream kernel builds. I think Leap only changes
the default compiler on major version changes, and Leap 15.0 was
released 7.5 years ago.

If gcc 8 is considered too old, that's fine with me, I can switch to
yet another compiler, but then Documentation/process/changes.rst should
be updated to reflect that. As long as our documentation says a
compiler is supported, I am willing to use it to verify if that's
actually true ;-)

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

On Wed, Dec 17, 2025 at 02:10:37PM +0100, Jean Delvare wrote:
> Hi Peter,
> 
> On Wed, 17 Dec 2025 13:47:13 +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:  
> > > > 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).
> 
> As an additional data point, clang 17.0.6 builds the kernel just fine
> for me.

Yeah, everything except gcc-8 so far. It really is a weird compiler
issue.

> > 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.
> 
> Actually the default C compiler on my openSUSE Leap 15.6 system is even
> gcc 7, I had to manually install gcc 8 and use CC= because gcc 7 is no
> longer supported for upstream kernel builds. I think Leap only changes
> the default compiler on major version changes, and Leap 15.0 was
> released 7.5 years ago.
> 
> If gcc 8 is considered too old, that's fine with me, I can switch to
> yet another compiler, but then Documentation/process/changes.rst should
> be updated to reflect that. As long as our documentation says a
> compiler is supported, I am willing to use it to verify if that's
> actually true ;-)

So strictly speaking gcc-8 should indeed build the kernel, and I'll try
and make this thing go away. But even so, you'll not get the best
possible kernel with gcc-8, it misses a ton of features.

I'm not saying you should move to gcc-16, but keeping up with the
compiler isn't a bad idea in general.

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

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 <linux/stringify.h>
 # 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 */

Re: Build breakage caused by the use of UDB

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 3903 bytes --]

On Wed, Dec 17, 2025 at 2:34 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> 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.

How about the attached patch that ensures that separator survives
macro expansion?

BR,
Uros.

[-- Attachment #2: p.diff.txt --]
[-- Type: text/plain, Size: 395 bytes --]

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 0e8c611bc9e2..76d2eb96dd49 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -17,7 +17,7 @@
 # define __ASM_REGPFX			%%
 #endif
 
-#define _ASM_BYTES(x, ...)	__ASM_FORM(.byte x,##__VA_ARGS__ ;)
+#define _ASM_BYTES(x, ...)	__ASM_FORM(.byte\t x,##__VA_ARGS__)
 
 #ifndef __x86_64__
 /* 32 bit */

Re: Build breakage caused by the use of UDB

[Jean Delvare]

On Wed, 17 Dec 2025 13:47:13 +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:  
> > > 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).

For the record, gcc 9.3.1 also fails to build kernel v6.18.1, for the
same reason.

-- 
Jean Delvare
SUSE L3 Support

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

On Wed, Dec 17, 2025 at 03:39:07PM +0100, Uros Bizjak wrote:

> > > 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.

> How about the attached patch that ensures that separator survives
> macro expansion?

Right, I think I tried that, it doesn't like things like retpoline.S

> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> index 0e8c611bc9e2..76d2eb96dd49 100644
> --- a/arch/x86/include/asm/asm.h
> +++ b/arch/x86/include/asm/asm.h
> @@ -17,7 +17,7 @@
>  # define __ASM_REGPFX			%%
>  #endif
>  
> -#define _ASM_BYTES(x, ...)	__ASM_FORM(.byte x,##__VA_ARGS__ ;)
> +#define _ASM_BYTES(x, ...)	__ASM_FORM(.byte\t x,##__VA_ARGS__)
>  
>  #ifndef __x86_64__
>  /* 32 bit */

$ make O=defconfig-build/ CC=gcc-8 arch/x86/lib/retpoline.o
make[1]: Entering directory '/mnt/nvme/linux-2.6/defconfig-build'
  GEN     Makefile
  CALL    ../scripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  AS      arch/x86/lib/retpoline.o
../arch/x86/include/asm/GEN-for-each-reg.h: Assembler messages:
../arch/x86/include/asm/GEN-for-each-reg.h:140: Error: bad expression
../arch/x86/include/asm/GEN-for-each-reg.h:6:  Info: macro invoked from here
../arch/x86/include/asm/GEN-for-each-reg.h:140: Error: junk at end of line, first unrecognized character is `t'

Which is why I ended up splitting the definition :/

Re: Build breakage caused by the use of UDB

[Uros Bizjak]

On Thu, Dec 18, 2025 at 9:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Dec 17, 2025 at 03:39:07PM +0100, Uros Bizjak wrote:
>
> > > > 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.
>
> > How about the attached patch that ensures that separator survives
> > macro expansion?
>
> Right, I think I tried that, it doesn't like things like retpoline.S
>
> > diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> > index 0e8c611bc9e2..76d2eb96dd49 100644
> > --- a/arch/x86/include/asm/asm.h
> > +++ b/arch/x86/include/asm/asm.h
> > @@ -17,7 +17,7 @@
> >  # define __ASM_REGPFX                        %%
> >  #endif
> >
> > -#define _ASM_BYTES(x, ...)   __ASM_FORM(.byte x,##__VA_ARGS__ ;)
> > +#define _ASM_BYTES(x, ...)   __ASM_FORM(.byte\t x,##__VA_ARGS__)
> >
> >  #ifndef __x86_64__
> >  /* 32 bit */
>
> $ make O=defconfig-build/ CC=gcc-8 arch/x86/lib/retpoline.o
> make[1]: Entering directory '/mnt/nvme/linux-2.6/defconfig-build'
>   GEN     Makefile
>   CALL    ../scripts/checksyscalls.sh
>   DESCEND objtool
>   INSTALL libsubcmd_headers
>   AS      arch/x86/lib/retpoline.o
> ../arch/x86/include/asm/GEN-for-each-reg.h: Assembler messages:
> ../arch/x86/include/asm/GEN-for-each-reg.h:140: Error: bad expression
> ../arch/x86/include/asm/GEN-for-each-reg.h:6:  Info: macro invoked from here
> ../arch/x86/include/asm/GEN-for-each-reg.h:140: Error: junk at end of line, first unrecognized character is `t'
>
> Which is why I ended up splitting the definition :/

I see... OTOH, a trivial solution would be to just use "ud2" mnemonic,
as proposed in [1].

[1] https://lore.kernel.org/lkml/20250909100038.1709394-1-ubizjak@gmail.com/

Uros.

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

On Thu, Dec 18, 2025 at 11:26:13AM +0100, Uros Bizjak wrote:

> I see... OTOH, a trivial solution would be to just use "ud2" mnemonic,
> as proposed in [1].
> 
> [1] https://lore.kernel.org/lkml/20250909100038.1709394-1-ubizjak@gmail.com/

Yes, there is that. I suppose I worry about all the other _ASM_BYTES
users, but since they don't actually show miscompilation, perhaps I
should not worry.

Let me do a build with just using ud2 instead.

Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

On Thu, Dec 18, 2025 at 11:38:53AM +0100, Peter Zijlstra wrote:
> On Thu, Dec 18, 2025 at 11:26:13AM +0100, Uros Bizjak wrote:
> 
> > I see... OTOH, a trivial solution would be to just use "ud2" mnemonic,
> > as proposed in [1].
> > 
> > [1] https://lore.kernel.org/lkml/20250909100038.1709394-1-ubizjak@gmail.com/
> 
> Yes, there is that. I suppose I worry about all the other _ASM_BYTES
> users, but since they don't actually show miscompilation, perhaps I
> should not worry.
> 
> Let me do a build with just using ud2 instead.

Yep, this builds. Let me stick a changelog on with Fixes and Cc stable
and stick it in x86/urgent.

---

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index d561a8443c13..9b4e04690e1a 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -15,7 +15,7 @@ extern void __WARN_trap(struct bug_entry *bug, ...);
 /*
  * Despite that some emulators terminate on UD2, we use it for WARN().
  */
-#define ASM_UD2		_ASM_BYTES(0x0f, 0x0b)
+#define ASM_UD2		__ASM_FORM(ud2)
 #define INSN_UD2	0x0b0f
 #define LEN_UD2		2
 

[tip: x86/urgent] x86/bug: Fix old GCC compile fails

[tip-bot2 for Peter Zijlstra]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     c56a12c71ad38f381105f6e5036dede64ad2dfee
Gitweb:        https://git.kernel.org/tip/c56a12c71ad38f381105f6e5036dede64ad2dfee
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Thu, 18 Dec 2025 11:47:38 +01:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 18 Dec 2025 11:55:40 +01:00

x86/bug: Fix old GCC compile fails

For some mysterious reasons the GCC 8 and 9 preprocessor manages to
sporadically fumble _ASM_BYTES(0x0f, 0x0b):

$ grep ".byte[ ]*0x0f" defconfig-build/drivers/net/wireless/realtek/rtlwifi/base.s
        1:       .byte0x0f,0x0b ;
        1:       .byte 0x0f,0x0b ;

which makes the assembler upset and all that. While there are more
_ASM_BYTES() users (notably the NOP instructions), those don't seem
affected. Therefore replace the offending ASM_UD2 with one using the
ud2 mnemonic.

Reported-by: Jean Delvare <jdelvare@suse.de>
Suggested-by: Uros Bizjak <ubizjak@gmail.com>
Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA")
Cc: stable@kernel.org
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20251218104659.GT3911114@noisy.programming.kicks-ass.net
---
 arch/x86/include/asm/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index ee23b98..40de579 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -15,7 +15,7 @@ extern void __WARN_trap(struct bug_entry *bug, ...);
 /*
  * Despite that some emulators terminate on UD2, we use it for WARN().
  */
-#define ASM_UD2		_ASM_BYTES(0x0f, 0x0b)
+#define ASM_UD2		__ASM_FORM(ud2)
 #define INSN_UD2	0x0b0f
 #define LEN_UD2		2
 

Re: Build breakage caused by the use of UDB

[Brian Gerst]

On Thu, Dec 18, 2025 at 5:48 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Dec 18, 2025 at 11:38:53AM +0100, Peter Zijlstra wrote:
> > On Thu, Dec 18, 2025 at 11:26:13AM +0100, Uros Bizjak wrote:
> >
> > > I see... OTOH, a trivial solution would be to just use "ud2" mnemonic,
> > > as proposed in [1].
> > >
> > > [1] https://lore.kernel.org/lkml/20250909100038.1709394-1-ubizjak@gmail.com/
> >
> > Yes, there is that. I suppose I worry about all the other _ASM_BYTES
> > users, but since they don't actually show miscompilation, perhaps I
> > should not worry.
> >
> > Let me do a build with just using ud2 instead.
>
> Yep, this builds. Let me stick a changelog on with Fixes and Cc stable
> and stick it in x86/urgent.
>
> ---
>
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index d561a8443c13..9b4e04690e1a 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -15,7 +15,7 @@ extern void __WARN_trap(struct bug_entry *bug, ...);
>  /*
>   * Despite that some emulators terminate on UD2, we use it for WARN().
>   */
> -#define ASM_UD2                _ASM_BYTES(0x0f, 0x0b)
> +#define ASM_UD2                __ASM_FORM(ud2)
>  #define INSN_UD2       0x0b0f
>  #define LEN_UD2                2
>
>

Replace all instances of ASM_UD2 with the instruction.  There is no
need to keep it now.


Brian Gerst