[Discuss] Test real Linux user program in zCore

[benpigchu]

@wfly1998 and @yunwei37 did some works to run shell, gcc and rustc in the linux part of zCore. Here we try to reproduce their works and attempt to find and fix the problem that breaks rustc.

Goals:

• Shell
  • libOS
  • qemu
• gcc
  • libOS
  • qemu
• rustc
  • libOS
  • qemu

Recourse:

• The report
• wfly1998's log
• yunwei37's log

[benpigchu]

Run the shell, The first attmpt

You can get the prebuilt Alpine Linux rootfs with:

make rootfs

Then you can run the shell in libOS with

cargo run --release -p linux-loader /bin/busybox sh

The internal commands works well

benpigchu@pikabox-rebirth:/mnt/c/root/works/code/git/zCore$ cargo run --release -p linux-loader /bin/busybox sh
    Finished release [optimized] target(s) in 2.05s
     Running `target/release/linux-loader /bin/busybox sh`
echo a
a
echo x
x
echo $PATH
/usr/sbin:/usr/bin:/sbin:/bin:/usr/x86_64-alpine-linux-musl/bin

However it is not possible to start a process in this shell. The shell uses fork to start a process, which do not works.

benpigchu@pikabox-rebirth:/mnt/c/root/works/code/git/zCore$ RUST_LOG=linux_syscall::task=info cargo run --release -p linux-loader /bin/busybox sh
   Compiling kernel-hal-unix v0.1.0 (/mnt/c/root/works/code/git/zCore/kernel-hal-unix)
   Compiling linux-loader v0.1.0 (/mnt/c/root/works/code/git/zCore/linux-loader)
    Finished release [optimized] target(s) in 23.45s
     Running `target/release/linux-loader /bin/busybox sh`
[ INFO][2] set_tid_address: 0x20029635c
[ INFO][2] getpid:
[ INFO][2] getppid:
echo a
[ INFO][2] wait4: target=AnyChild, wstatus=0x20029e96c, options=NOHANG
a
ls
[ INFO][2] fork:
[ INFO][2] fork: 1027 -> 1038
[ INFO][3] gettid:
[ INFO][2] wait4: target=AnyChild, wstatus=0x20029e94c, options=(empty)
echo

However, vfork should be working in zCore. This means we should build busybox by ourselves to make it use rootfs instead.
See instruction for building busybox for embedded platforms like Linux on zCore

[benpigchu]

Run shell with customized busybox

@wangrunji0408 sent me a prebuilt busybox binary with NOMMU option.
However this somehow does not work on libOS.

benpigchu@pikabox-rebirth:/mnt/c/root/works/code/git/zCore$ RUST_BACKTRACE=1 cargo run --release -p linux-loader /bin/busybox-nommu sh
    Finished release [optimized] target(s) in 1.31s
     Running `target/release/linux-loader /bin/busybox-nommu sh`
uname
thread 'async-std/runtime' panicked at 'not implemented', /home/benpigchu/.cargo/git/checkouts/rcore-fs-7fdf258332f6146d/517af47/rcore-fs/src/std.rs:25:18
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:486
  11: std::panicking::begin_panic
  12: rcore_fs::std::<impl core::convert::From<std::io::error::Error> for rcore_fs::vfs::FsError>::from
  13: rcore_fs_hostfs::HNode::open_file
  14: <rcore_fs_hostfs::HNode as rcore_fs::vfs::INode>::read_at
  15: <rcore_fs_mountfs::MNode as rcore_fs::vfs::INode>::read_at
  16: <dyn rcore_fs::vfs::INode as linux_object::fs::INodeExt>::read_as_vec
  17: linux_syscall::task::<impl linux_syscall::Syscall>::sys_execve
  18: linux_syscall::Syscall::syscall::{{closure}}
  19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  20: std::thread::local::LocalKey<T>::with
  21: async_task::raw::RawTask<F,R,S,T>::run
  22: multitask::Ticker::tick
  23: async_executor::Executor::run
  24: core::ops::function::FnOnce::call_once{{vtable.shim}}
  25: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/56daaf669ebc3d5083db5cded719f780dc31104e/src/liballoc/boxed.rs:1076
  26: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/56daaf669ebc3d5083db5cded719f780dc31104e/src/liballoc/boxed.rs:1076
  27: std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:87
  28: start_thread
             at /build/glibc-YYA7BZ/glibc-2.31/nptl/pthread_create.c:477
  29: __clone
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Is this a Host filesystem related issue?

[benpigchu]

The correct way to ls is ... use busybox ls instead

benpigchu@pikabox-rebirth:/mnt/c/root/works/code/git/zCore$ RUST_BACKTRACE=full cargo run --release -p linux-loader /bin/busybox-nommu sh
    Finished release [optimized] target(s) in 1.18s
     Running `target/release/linux-loader /bin/busybox-nommu sh`
busybox-nommu ls
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

However it is still a bug to panic instead of error when there is no required binary, see rcore-os/rcore-fs#20
Or: just create a link

[yunwei37]

Maybe some error is because the command in /bin is linked to /bin/busybox by abstract path, this will make the rcore-fs search the path in your local machine instead of the rootfs folder...

you can change the link of command file to the relative path, in this case the command is supposed to run properly: #149

[yukiiiteru]

I'm sorry I was busy with something recently and I've seen this issue just now.

The usage of Linux shell and GCC in LibOS and QEMU had been written in usage.md, all the precautions are written here, please check.