Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Nov 21, 2025 at 10:41:46PM +0900, Alexandre Courbot wrote:
> On Fri Nov 21, 2025 at 6:08 PM JST, Alice Ryhl wrote:
> > On Fri, Nov 21, 2025 at 03:13:16PM +0900, Alexandre Courbot wrote:
> >> On Fri Nov 21, 2025 at 1:41 AM JST, kernel test robot wrote:
> >> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> >> > head:   88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
> >> > commit: 01e345e82ec3a5a7edeb9fa0dcb7fd4b0e5c534e [9676/10599] rust: num: add Bounded integer wrapping type
> >> > config: loongarch-randconfig-6002-20251120 (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/config)
> >> > compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
> >> > rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
> >> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251121/202511210055.RUsFNku1-lkp@intel.com/reproduce)
> >> >
> >> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >> > the same patch/commit), kindly add following tags
> >> > | Reported-by: kernel test robot <lkp@intel.com>
> >> > | Closes: https://lore.kernel.org/oe-kbuild-all/202511210055.RUsFNku1-lkp@intel.com/
> >> >
> >> > All errors (new ones prefixed by >>):
> >> >
> >> >>> ld.lld: error: undefined symbol: rust_build_error
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u8, 1>>::from_expr) in archive vmlinux.a
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u32, 4>>::from_expr) in archive vmlinux.a
> >> >    >>> referenced by build_assert.rs:83 (rust/kernel/build_assert.rs:83)
> >> >    >>>               rust/doctests_kernel_generated.o:(<kernel::num::bounded::Bounded<u16, 8>>::from_expr) in archive vmlinux.a
> >> 
> >> Mmm, I don't like this. The expressions that are failing are extremely
> >> simple, for instance:
> >> 
> >>     Bounded::<u8, 1>::from_expr(1)
> >> 
> >> So if the compiler is unable to assess that this won't fail, this might
> >> be a deal-breaker for `from_expr` and we might need to remove it. :(
> >> 
> >> This would also mean a lot more runtime checks when working with
> >> bitfields and registers. Or can we assume that this is a compiler
> >> problem on this particular architecture?
> >
> > Yeah, it sounds like from_expr() isn't going to work.
> 
> It would be a pity but we can replace `from_expr` with an unsafe
> `new_unchecked` for these cases where the caller is absolutely sure of
> their input. I have tried on bitfield/Nova and the result is not too
> bad.
> 
> Still, this is a bummer - it is much better to have the compiler
> validate safety properties than relying on a SAFETY comment.

This kind of thing is why I keep saying build_error() is too fragile to
be used at all.

> I notice that loongarch is a Tier 2 Rust platform, but I suppose that's
> not an excuse to let it not build? ^_^;

What Tier upstream Rust uses for the target is irrelevant for us IMO.

Or at least, it may be relevant in the "add this target to Linux?"
discussion. But once we added it, it's not relevant anymore.

> If I had to bet I'd wager that in this case the "shift left then back
> right" technique to check the bounds is not working well. I will try to
> find an alternative, but meanwhile we should probably remove
> `from_expr`. I will send a patch to that effect unless told otherwise.

Alice