Incorrect panic message from ilog0 of 1 on aarch64-unknown-none

[kirtchev-adacore]

I tried this code on aarch64-unknown-none:

// Extracted from library/core/tests/num/int_log.rs.

#![feature(lang_items)]
#![no_main]
#![no_std]

use core::ffi::c_int;
use core::ffi::c_void;
use core::panic::PanicInfo;

fn ilog0_of_1_panic() {
    let _ = 1u32.ilog(0);
}

extern "C" {
    fn _exit(status: c_int) -> !;
    fn write(fd: c_int, buf: *const c_void, count: c_int) -> c_int;
}

#[lang = "eh_personality"]
fn eh_personality() {}

fn exit(status: c_int) -> ! {
    unsafe {
        _exit(status);
    }
}

fn output(message: &str) {
    unsafe {
        write(2, message.as_ptr() as _, message.len() as _);
    }
}

#[panic_handler]
fn panic(info: &PanicInfo<'_>) -> ! {
    output(&"  panicked\n");

    let payload = info.payload().downcast_ref::<&str>();

    match payload {
        Some(&actual_message) if actual_message == "base of integer logarithm must be at least 2" => {
            output(&"    message ok\n");
            exit(0);  // Expected outcome.
        }
        None if "base of integer logarithm must be at least 2" == "" => {
            output(&"    no message\n");
            exit(0);  // Expected outcome.
        }
        _ => {
            output(&"    unexpected outcome\n");
            exit(1);  // Unexpected outcome.
        }
    }
}

#[no_mangle]
extern "C" fn main() {
    output(&"running\n");

    ilog0_of_1_panic();

    output(&"  did not panic\n");
    exit(1);  // Unexpected outcome.
}

The code shown above was produced by a script, hence some of the silliness.

I expected to see this happen:

1u32.ilog(0) should have panicked with message "base of integer logarithm must be at least 2", thus resulting in the following output:

running
  panicked
    message ok

Instead, this happened:

running
  panicked
    unexpected output

In gdb, the value of payload is core::option::Option<&&str>::None.

Compilation command:

rustc \
--edition=2021 \
--target=aarch64-unknown-none \
-A warnings \
-C debuginfo=2 \
-C linker=aarch64-elf-gcc \
-C link-arg=-Lpath_to_linker_script \
-C link-arg=-Tlscript.ld \
-C link-arg=-Lpath_to_bsp \
-C link-arg=-nostartfiles \
-C link-arg=-Wl,-v \
-C link-arg=-Wl,--start-group,-lbsp,-lgcc,-lgcc_eh,-lc,--end-group \
-C panic=abort \
main.rs

I have the sneaking suspicion that unwinding is taking place and is blowing up something (the stack? the unwinding stack?) which in turn generates a new panic with no message. gdb shows a call stack with thousands of frames, all pointing to core::panicking::panic_fmt, but then again this could be a gdb issue.

Shouldn't panic_nounwind_fmt be called instead, given that the panic_strategy on aarch64-uknown-none is Abort?

Meta

rustc --version --verbose:

rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: x86_64-unknown-linux-gnu
release: 1.78.0
LLVM version: 18.1.2

Backtrace

<backtrace>

[kirtchev-adacore]

I am closing this issue as this was a pilot error on my part. One should use message() to obtain the panic message, not payload(). After some tweaking of the boiler plate code, I was able to compare the panic message against the expectation.

Sorry for the noise!