The value forced to & str from && str has zero values ​​for bare metal

Question

Here is a minimal example:

lib.rs:

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

extern crate rlibc;
extern crate libc;

use libc::{c_int, c_char};

#[no_mangle] // just for easier llvm-ir reading
fn foo(baz: &str) -> usize {
    baz.len()
}

#[no_mangle]
pub extern fn main(_argc: c_int, _argv: *const *const c_char) -> c_int {
    let gdb_wait = true; // for debugging with gdb
    while unsafe { core::ptr::read_volatile(&gdb_wait) } {}

    assert_eq!(foo(&"bar_fail"), 0);
    assert_eq!(foo("bar_ok"), 6);

    loop {}
}

// just some functions to run on bare metal.

#[lang = "panic_fmt"]
#[no_mangle]
pub extern fn rust_begin_panic(_msg: core::fmt::Arguments, _file: &'static str, _line: u32) -> ! {
    loop {}
}

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

#[allow(non_snake_case)]
#[no_mangle]
pub extern "C" fn _Unwind_Resume() -> ! { loop {} }

#[no_mangle]
pub extern fn fmod(_: f64, _: f64) {
    loop {  }
}

#[no_mangle]
pub extern fn fmodf(_: f32, _: f32) {
    loop {  }
}

The main function is called asm on qemu-system-x86_64 in mode with a length of 64 bits.

GDB output from the first call on transfer &&str. This does not work:

(gdb) print baz
$1 = {data_ptr = 0x0, length = 0}

GDB output of the second call during transmission &str. This works great:

(gdb) print baz
$2 = {data_ptr = 0xffffffff80133460 <str4498> "bar_oksrc/lib.rsassertion failed: `(left == right)` (left: ``, right: ``)\001gdb_load_rust_pretty_printers.py", length = 6}

Here is a complete executable project .

Answer 1

The problem is solved by editing the linker script. The string was placed after the bss section in memory. Therefore, multiboot filled it with zeros.