Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
"Arnd Bergmann" <[email protected]>
| Newsgroups | gmane.linux.uml.devel,gmane.linux.ports.arm.kernel,gmane.linux.kbuild.devel,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.kernel.rust |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Mar 30, 2026, at 23:09, Christian Schrefl wrote: > On 3/26/26 6:30 PM, Miguel Ojeda wrote: >> On Thu, Mar 26, 2026 at 4:18 PM Russell King (Oracle) >> <[email protected]> wrote: >>> >>> I'm not sure if this is still true, but I believe it used to be the case >>> that the -linux-gnueabi target has one behaviour for enums (fixed size) >>> whereas -none-eabi, the size of the type depends on the range of values >>> included in the enum. >>> >>> Certianly, when Arm Ltd were proposing EABI, EABI had the latter >>> behaviour, and I think there were cases where Linux used "enum" in >>> its UAPI. >> >> Short enums? I see `c-enum-min-bits` in the armv7a-none-eabi built-in >> `rustc` target, and indeed: >> >> #![no_std] >> >> #[repr(C)] >> enum T { >> A, >> B, >> } >> >> pub static S: usize = core::mem::size_of::<T>(); >> >> is 1 for that one, and 4 for the other. > > I guess we could use a custom target spec, but I'm not > sure if that is worth the hassle of adding another one. The kernel Makefile forces the Linux enum behavior using arch/arm/Makefile:CFLAGS_ABI :=-mabi=aapcs-linux -mfpu=vfp ifeq ($(CONFIG_CC_IS_CLANG),y) CFLAGS_ABI += -meabi gnu endif KBUILD_RUSTFLAGS += --target=arm-unknown-linux-gnueabi regardless of the compiler. I think this should be safe for any combination of C and rust compilers. Arnd