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

[Gary Guo <gary@garyguo.net>]

On Mon, 24 Nov 2025 10:37:08 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> On Fri, Nov 21, 2025 at 04:53:26PM +0100, Miguel Ojeda wrote:
> > 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.  
> 
> I don't think it is like that at all. We rely on non-guaranteed behavior
> for data races because we have no choice and we had extensive discussion
> about it with the compiler folks who are comfortable with us using that
> particular exception.

This is not about LKMM but that BUILD_BUG_ON also relies on compiler
optimizations and reference undefined symbols if compiler cannot
optimize them out.

`build_assert` is just a nicer Rust way of the same trick.

> 
> > 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.  
> 
> The difference is that someone adding unsafe to avoid a bounds check
> screams to the reviewers that something sketchy is going on. In
> comparison, drivers calling `Bounded::from_expr(_)` with a non-trivial
> expression looks like entirely normal code even though it might be
> relying on the precise and definitely subject-to-change details of when
> LLVM is choosing to inline various functions.
> 
> If const eval / generics / macros are too painful, then perform a
> runtime bounds check just like everyone who uses Rust outside of the
> kernel is doing.

There're 200+ uses of BUILD_BUG_ON in include/. I see this case being
similar to those usages.

> 
> > 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.  
> 
> I do not at all think it's obvious that upstream would be happy about
> this, considering it comes with the serious trade-off of us relying on
> these optimizations happening.

If the exact use case does not involve a reference, it's exactly same
as BUILD_BUG_ON, so would be a LLVM bug that equally affect
clang-built-linux.

Best,
Gary