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

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

[kernel test robot]

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

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Alexandre Courbot]

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?

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

[Alice Ryhl]

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.

Alice

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

[Alexandre Courbot]

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.

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

[Alice Ryhl]

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

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

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> This kind of thing is why I keep saying build_error() is too fragile to
> be used at all.

Adding `unsafe` blocks for things that should be able to be statically
known isn't great.

`build_assert!` is just too useful, so it is best to try to understand
what can be done, or find an equivalent solution. Gary et al. may have
some input here.

Perhaps we need to resort to a macro, that would at least be better
than adding `unsafe` blocks. It is what C does in many cases, after
all.

Cheers,
Miguel

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

[Gary Guo]

On Fri, 21 Nov 2025 15:21:45 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > This kind of thing is why I keep saying build_error() is too fragile to
> > be used at all.  

The case here I think is a perfectly fine use case of `build_error` as
it's completely by-value and does involve references. If compiler can't
figure out, it's either a compiler bug or a source bug.

> Adding `unsafe` blocks for things that should be able to be statically
> known isn't great.
> 
> `build_assert!` is just too useful, so it is best to try to understand
> what can be done, or find an equivalent solution. Gary et al. may have
> some input here.

I'd argue that these build issues actually helps us catch missed
optimisations opportunities :)

For this particular issue, I noticed that none of the functions
involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
I suspect after marking them as inline this case should be resolved.

Best,
Gary

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

[Alexandre Courbot]

On Fri Nov 21, 2025 at 11:30 PM JST, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>> >
>> > This kind of thing is why I keep saying build_error() is too fragile to
>> > be used at all.  
>
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.
>
>> Adding `unsafe` blocks for things that should be able to be statically
>> known isn't great.
>> 
>> `build_assert!` is just too useful, so it is best to try to understand
>> what can be done, or find an equivalent solution. Gary et al. may have
>> some input here.
>
> I'd argue that these build issues actually helps us catch missed
> optimisations opportunities :)
>
> For this particular issue, I noticed that none of the functions
> involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
> I suspect after marking them as inline this case should be resolved.

Indeed. Another thing that caught my attention is that the `num_bits`
parameter of `fits_within` could be turned into a const generic.

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

[Alice Ryhl]

On Fri, Nov 21, 2025 at 02:30:08PM +0000, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> 
> > On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
> > >
> > > This kind of thing is why I keep saying build_error() is too fragile to
> > > be used at all.  
> 
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.

The thing about this particular case is that it should have been

	const { Bounded::<u8, 1>::from_expr(1) }

or similar.

You say that this kind of thing would be a compiler bug, but I don't
think the compiler devs folks would agree with us on that at all. I
mean, sure, it's a bug in the sense that it's a missed optimization, but
it's not a correctness bug.

If we used const eval, then suddenly it *would* easily be a compiler
bug, and by the way, it would also work reliably.

> > Adding `unsafe` blocks for things that should be able to be statically
> > known isn't great.
> > 
> > `build_assert!` is just too useful, so it is best to try to understand
> > what can be done, or find an equivalent solution. Gary et al. may have
> > some input here.

I'm not advocating for adding unsafe blocks to skip bounds checks.

And, fine, there are probably a few cases where it works reliably and
has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
do not think bounds checks are a place where it's a good idea.

Alice

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

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 3:44 PM Alice Ryhl <aliceryhl@google.com> wrote:
>
> You say that this kind of thing would be a compiler bug, but I don't
> think the compiler devs folks would agree with us on that at all. I
> mean, sure, it's a bug in the sense that it's a missed optimization, but
> it's not a correctness bug.

> I'm not advocating for adding unsafe blocks to skip bounds checks.
>
> And, fine, there are probably a few cases where it works reliably and
> has no real replacement. Such as the VTABLE_DEFAULT_ERROR check. But I
> do not think bounds checks are a place where it's a good idea.

There may be no guarantees, but it is a similar situation as for C
compilers in the kernel.

Compilers can of course change behavior and have bugs and so on, and
thus avoiding to rely on it as much as possible is a good idea, but I
think it is a good idea to get build asserts reliably working as much
as possible for certain use cases. In particular, I don't see why
simple (local-enough) bounds checks cannot be one of those (it may not
be today, but it could).

Of course, the best would be to get the language to a point where it
supports this sort of thing natively. But that is a longer road.

And, in some situations, there may be no good alternative (i.e. const
eval / generics / macros may be too painful to apply), and thus people
may end up adding `unsafe` instead, which isn't great.

In addition, I think upstream probably wants to know about this sort
of this, i.e. sometimes the changes may be unintended (i.e. if we see
it changing in a new nightly) and they probably like to hear about
"obvious" optimizations not being applied, since they are potential
easy wins for them (or, rather, avoiding regressions), as Gary
mentions. That is also part of the value of building the kernel in
compiler CIs etc.

Cheers,
Miguel

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

[Alexandre Courbot]

On Fri Nov 21, 2025 at 11:30 PM JST, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>> >
>> > This kind of thing is why I keep saying build_error() is too fragile to
>> > be used at all.  
>
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.
>
>> Adding `unsafe` blocks for things that should be able to be statically
>> known isn't great.
>> 
>> `build_assert!` is just too useful, so it is best to try to understand
>> what can be done, or find an equivalent solution. Gary et al. may have
>> some input here.
>
> I'd argue that these build issues actually helps us catch missed
> optimisations opportunities :)
>
> For this particular issue, I noticed that none of the functions
> involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
> I suspect after marking them as inline this case should be resolved.

The failing config features this setting:

    CONFIG_CC_OPTIMIZE_FOR_SIZE=y

I don't know whether this "CC" setting also affects Rust, but assuming
it does, we can very well imagine that at least one of
`from_expr`/`fits_within` does not get inlined, causing the compiler to
not be able to satisfy the `build_assert`.

If that's true, then this is an oversight of mine rather than a
fundamental problem, and could affect all architectures. I'll try to
reproduce the issue locally to test this theory.

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

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 4:27 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
>     CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>
> I don't know whether this "CC" setting also affects Rust, but assuming
> it does, we can very well imagine that at least one of
> `from_expr`/`fits_within` does not get inlined, causing the compiler to
> not be able to satisfy the `build_assert`.
>
> If that's true, then this is an oversight of mine rather than a
> fundamental problem, and could affect all architectures. I'll try to
> reproduce the issue locally to test this theory.

Yes, it does affect Rust, i.e. we use the same levels for both.

Would `inline(always)` work?

Cheers,
Miguel

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

[Alexandre Courbot]

On Sat Nov 22, 2025 at 12:30 AM JST, Miguel Ojeda wrote:
> On Fri, Nov 21, 2025 at 4:27 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>>     CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>>
>> I don't know whether this "CC" setting also affects Rust, but assuming
>> it does, we can very well imagine that at least one of
>> `from_expr`/`fits_within` does not get inlined, causing the compiler to
>> not be able to satisfy the `build_assert`.
>>
>> If that's true, then this is an oversight of mine rather than a
>> fundamental problem, and could affect all architectures. I'll try to
>> reproduce the issue locally to test this theory.
>
> Yes, it does affect Rust, i.e. we use the same levels for both.
>
> Would `inline(always)` work?

I've repro'd the issue locally using the very helpful script mentioned
in the report, and confirmed that `#[inline(always)]` fixes the problem!

Preparing a patch. :)

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

[Miguel Ojeda]

On Fri, Nov 21, 2025 at 2:41 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> I notice that loongarch is a Tier 2 Rust platform, but I suppose that's
> not an excuse to let it not build? ^_^;

x86_64, arm64 and riscv64 should be kept working, and I also
build-test loongarch64, including for stable kernels.

arm32 and UML are the ones that are best-effort (on my side at least)
so we play catch up as time allows, but loongarch64 so far should
always build and it would be sad to drop that.

I don't see this in my tests (though I see another issue for
loongarch64; I will send a few emails), so it may depend on the
config.

Cc'ing our toolchain experts and the loongarch maintainers.

Cheers,
Miguel