Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discuss] Test real Linux user program in zCore #177

Open
2 of 9 tasks
benpigchu opened this issue Sep 19, 2020 · 5 comments
Open
2 of 9 tasks

[Discuss] Test real Linux user program in zCore #177

benpigchu opened this issue Sep 19, 2020 · 5 comments

Comments

@benpigchu
Copy link
Contributor

benpigchu commented Sep 19, 2020

@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:

@benpigchu
Copy link
Contributor Author

benpigchu commented Sep 19, 2020

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
Copy link
Contributor Author

benpigchu commented Sep 19, 2020

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
Copy link
Contributor Author

benpigchu commented Sep 22, 2020

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
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants