Rust with [no_std] & CustomAllocator -> rust_oom either undefined in link stage or already defined in compile stage :/

[2ndTaleStudio]

Hi there,

i'm a bit new to rust and writing a library for embedded Raspberry Pi bare metal programming. I'm completely using #![no_std] in all of my crates. However, at a certain point functions of the alloc crate are needed. So I came accross the option to implement a custom GlobalAllocator as per the doc: (https://doc.rust-lang.org/core/alloc/trait.GlobalAlloc.html).

However, when compiling this the crate also requires an alloc_error_handler present like so:

#![no_std]
#![feature(alloc_error_handler)]

#[global_allocator]
static ALLOCATOR: RusPiRoAllocator = RusPiRoAllocator;
[...] here comes the implementation of the allocator [...]
#[alloc_error_handler]
fn alloc_error_handler(_: Layout) -> ! {
    // TODO: how to handle memory allocation errors?
    loop { }
}

However, doing so compilation works fine, but using this crate in an actual binary to be build as a dependency lead to the linker error undefined reference to 'rust_oom'.

So well I just put this into the code as well:

#[alloc_error_handler]
fn alloc_error_handler(_: Layout) -> ! {
    // TODO: how to handle memory allocation errors?
    loop { }
}

#[no_mangle]
fn rust_oom() -> ! {
    // well, currently there is nothing we could do on out-of-memory other than halt the core
    loop { }
}

BUT, doing so the compiler complains that the function rust_oom has already being defined. So for whatever reason the compiler seem to optimize the rust_oom function away before linking. As a workaround I put the rust_oom function into a separate crate the allocator crate depends on. (you can find the whole code here: ruspiro-allocator.

With this workaround in place the building of the binary works fine as long as the ruspiro-allocator crate is a direct dependency of it. I would rather like to bundle other crates of mine into a new crate that makes it easier to consume and may need only one dependency in the binary to be created with some feature gates but not many...

So I created a crate, lets call it kernel-crate that represents the final binary to be build. This crate has a dependency to a library-crate which depends on allocator-crate.
In this scenario the linker will again complain that the reference to rust_oom is undefined. So somewhere down the route the function seem to be optimized away again...
But if kernel-crate directly depends on allocator-crate everything works fine....

I would appreciate if someone could shed a light on the issue and how to solve it properly.

Btw. I'm building for the target armv7-unknown-linux-gnueabihf, cross compiling from a windows host machine with cargo version:

cargo 1.38.0-nightly (677a180f4 2019-07-08)

Any hint would be much appreciated...
Thanks in advance.

[hellow554]

The issue tracker is for reporting errors in the compiler or language itself. If you need help with something, just go to the user forum at https://users.rust-lang.org or https://stackoverflow.com/questions/tagged/rust .

[2ndTaleStudio]

Hi,
sorry if I used this channel the wrong way.
However,l for me it pretty much feels like an issue with the compiler or linker and how the rust_oom function is implemented and suddenly stripped away by the compiler. I mean, why is not having the function leads to "undefined reference" but implementing it at the right place leads to "symbol already defined" ? Don't you think this is a bug in the compiler?

[bjorn3]

#112331 will probably fix this as side effect once it gets merged if this issue still exists at all. With that PR #[alloc_error_handler] and rust_oom no longer exist.