On Thu, 10 Sep 2026 13:05:27 +0100
"Gary Guo" <[email protected]> wrote:
> On Thu Sep 10, 2026 at 11:08 AM BST, Mukesh Kumar Chaurasiya (IBM) wrote:
>> The Rust kernel infrastructure generates inline asm for WARN() via
>> ARCH_WARN_ASM(file, line, flags, size), expanding it through a C
>> preprocessor pass (generated_arch_warn_asm.rs.S) to produce an
>> arch-specific asm template string for use in Rust's core::arch macros.
>>
>> powerpc currently lacks ARCH_WARN_ASM and ARCH_WARN_REACHABLE, causing
>> Rust builds to fail on powerpc with
>> ```
>> error: no rules expected `ARCH_WARN_ASM`
>> -->
>> /home/linkmauve/dev/linux/wii/rust/kernel/generated_arch_warn_asm.rs:1:28
>> |
>> 1 | ::kernel::concat_literals!(ARCH_WARN_ASM("{file}", "{line}",
>> "{flags}", "{size}"))
>
> I think we probably want to catch this earlier by have something like
>
> #ifndef ARCH_WARN_ASM
> #error "ARCH_WARM_ASM is not defined"
> #endif
>
> in generated_arch_warn_asm.rs.S.
Good idea.
One thing needs to be fixed first. arm and loongarch do not define
ARCH_WARN_ASM. rust/kernel/bug.rs uses bindings::WARN_ON() on those
architectures, so it never includes generated_arch_warn_asm.rs. But
rust/Makefile still generates the file for them. With #error, their
builds would break.
I think we should add a condition to rust/Makefile to stop generating
the file for arm and loongarch. Then #error can be unconditional.
Does that sound reasonable? I can send patches.
>> arch/powerpc/include/asm/bug.h | 36 +++++++++++++++++++---------------
>> 1 file changed, 20 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>> index 0db48977c70c..df2183c35945 100644
>> --- a/arch/powerpc/include/asm/bug.h
>> +++ b/arch/powerpc/include/asm/bug.h
>> @@ -32,34 +32,38 @@
>> #endif /* verbose */
>>
>> #else /* !__ASSEMBLER__ */
>> -/* _EMIT_BUG_ENTRY expects args %0,%1,%2,%3 to be FILE, LINE, flags and
>> - sizeof(struct bug_entry), respectively */
>> #ifdef CONFIG_DEBUG_BUGVERBOSE
>> -#define _EMIT_BUG_ENTRY \
>> - ".section __bug_table,\"aw\"\n" \
>> - "2: .4byte 1b - .\n" \
>> - " .4byte %0 - .\n" \
>> - " .short %1, %2\n" \
>> - ".org 2b+%3\n" \
>> - ".previous\n"
>> +#define _EMIT_BUG_ENTRY(label, file, line, flags) \
>> + ".section __bug_table,\"aw\"\n" \
>> + "2: .4byte " label "b - .\n" \
>
> "b" is part of the label. "1b" itself is a label and "1" is just an integer.
>
> If the code uses
>
> _EMIT_BUG_ENTRY(..)
> "1: ..."
>
> then the correct label would be "1f".
Agreed.
I think keeping the label fixed, as v2 did, would be fine too. x86,
arm64 and riscv all hardcode it. A comment that says the caller must
put the trap at 1: might be enough.
