On Tue, Jan 06, 2026 at 10:03:10AM +0100, Alice Ryhl wrote:
On Mon, Jan 5, 2026 at 6:03 PM Yury Norov yury.norov@gmail.com wrote:
On Mon, Jan 05, 2026 at 10:44:06AM +0000, Alice Ryhl wrote:
atus: O Content-Length: 4697 Lines: 121
On 32-bit ARM, you may encounter linker errors such as this one:
ld.lld: error: undefined symbol: _find_next_zero_bit >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0 >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.aThis error occurs because even though the functions are declared by include/linux/find.h, the definition is #ifdef'd out on 32-bit ARM. This is because arch/arm/include/asm/bitops.h contains:
#define find_first_zero_bit(p,sz) _find_first_zero_bit_le(p,sz) #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off) #define find_first_bit(p,sz) _find_first_bit_le(p,sz) #define find_next_bit(p,sz,off) _find_next_bit_le(p,sz,off)And the underscore-prefixed function is conditional on #ifndef of the non-underscore-prefixed name, but the declaration in find.h is *not* conditional on that #ifndef.
To fix the linker error, we ensure that the symbols in question exist when compiling Rust code. We do this by definining them in rust/helpers/ whenever the normal definition is #ifndef'd out.
Note that these helpers are somewhat unusual in that they do not have the rust_helper_ prefix that most helpers have. Adding the rust_helper_ prefix does not compile, as 'bindings::_find_next_zero_bit()' will result in a call to a symbol called _find_next_zero_bit as defined by include/linux/find.h rather than a symbol with the rust_helper_ prefix. This is because when a symbol is present in both include/ and rust/helpers/, the one from include/ wins under the assumption that the current configuration is one where that helper is unnecessary. This heuristic fails for _find_next_zero_bit() because the header file always declares it even if the symbol does not exist.
The functions still use the __rust_helper annotation. This lets the wrapper function be inlined into Rust code even if full kernel LTO is not used once the patch series for that feature lands.
Cc: stable@vger.kernel.org Fixes: 6cf93a9ed39e ("rust: add bindings for bitops.h") Reported-by: Andreas Hindborg a.hindborg@kernel.org Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/56167730... Signed-off-by: Alice Ryhl aliceryhl@google.com
Which means, you're running active testing, which in turn means that Rust is in a good shape indeed. Thanks to you and Andreas for the work.
I've put together this collection of GitHub actions jobs that build and test a few common configurations, which I used to test this: https://github.com/Darksonn/linux
Before I merge it, can you also test m68k build? Arm and m68k are the only arches implementing custom API there.
I ran a gcc build for m68k with these patches applied and it built successfully for me.
Thanks, Alice! Added in -next for testing. I'm going to send PR with the next -rc as it's a real build fix.
Dirk and everyone, please send your tags before the end of the week, if you want.
Thanks, Yury