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

[Alice Ryhl <aliceryhl@google.com>]

On Mon, Nov 24, 2025 at 02:48:10PM +0000, Gary Guo wrote:
> 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.

But we're no longer using it in the same way as BUILD_BUG_ON.

> > > 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.

I looked through a lot of the cases where BUILD_BUG_ON is used. All of
them seem to be checking that some constants are equal to something,
different from something, less than something, etc. It compares #defined
constants, and stuff like sizeof(struct) and such. But I could not find
even a single example where BUILD_BUG_ON used for bounds-checking a
runtime value, which is the use-case I think is problematic.

> > > 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.

If there's no reference, function boundary, or non-constant value, then
I don't think it's problematic. The problem IMO is using build_error for
bounds checking runtime values.

Alice