Format and panic behaving unexpected on bare metal target


#1

so recently i’ve been working on a little rust / aarch64 / raspberry pi kernel and it was going well until i encountered these two (possibly related?) bugs in the system. first and foremost the panic_fmt lang item does not seem to be called on panic. i have implemented this behaviour before without any problem and even used that same code so i assume that it’s correct.

#[no_mangle]
#[lang = "panic_fmt"]
pub extern fn panic(message: core::fmt::Arguments, file: &'static str, line: u32, column: u32) -> ! {
    log!(" [ panic ] fatal error; file {}; line {}; column {}", file, line, column);
    log!("{}", message);
    loop {}
}

there really isn’t that much room for error here since the function is being exported and seems valid in itself. the second bug is what made me create this topic because it seems like somewhat of an internal rust issue(?). there are some functions in rust core that will make the kernel crash / panic, can’t really tell because of the first problem. there are a couple of factors that play into this, like for example (using rust core fmt):

log!("test {}", 5);

will run successfully

log!("test {}", 200);

will fail

log("test {:x}", 200);
log("test {:b}", 200);

will run aswell

this was all tested mutliple times on actual devices with the same result. calling .bytes() on a str is crashing / panicing aswell (.chars() is not). i tried looking at the implementation for these cases but did not find anything that made them different from other functions i use without any problems.

feel free to take a shot in the dark if you have any ideas on what might be causing this. i appreciate the help


#2

If you’re on a recent nightly, then maybe this has something to do with it? PSA: [breaking-change] `panic_fmt` language item removed in favor of #[panic_implementation]


#3

that seems to have fixed the panic_fmt item, thought using the PanicInfo i get from the panic function in the formatter actually crashes (nothing happens and only restarting will help). i also found out that the formatter will also crash if the number of fmt::Arguments is more that one. knowing that formatting 5 works but 200 doesn’t, i can imagine it being connected to the number of characters that are supposed to be printed.

edit: formatting any number in decimal with more that one character crashes. formatting in binary or hexadecimal works fine for up to one value (per call to fmt::write_str). should i file a bug report on this?

edit2: the same crash also occurs upon reading a const value that was implemented for an enum. execution stops as soon as the value is being read form memory.