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

["Alexandre Courbot" <acourbot@nvidia.com>]

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.

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

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.