Show as the image, when I run the apps(helloworld), the cargo building system shows the error messages about missing rust -objcopy libs. How can I solve this problem?

I am running the shell app. If I use cargo update to update the dependencies, log-related errors will appear in the rust-fatfs library.

This error is because this library has customized its own log-related macros, but the current version is no longer applicable. Is it possible to re-fork this library and make modifications?

I'm trying to merge 10a536f from eb18704. All changes can be found here. And I'm refactoring packages in eb18704 , starting from the leaf node of the dependencies graph.
I will keep following up on updates of both repositories. Please don't hesitate to reach out to me.

graph TD;
axsync-->axdisplay
axdriver-->axdisplay

axhal-->axdriver
axalloc-->axdriver
axconfig-->axdriver

axdriver-->axfs
axsync-->axfs
axtask-.dev.->axfs

axtask-->axfs_os
axfs-->axfs_os

axconfig-->axhal
axalloc-->axhal
axlog-->axhal

axhal-->axnet
axsync-->axnet
axtask-->axnet
axdriver-->axnet

axalloc-->axruntime
axconfig-->axruntime
axdriver-->axruntime
axhal-->axruntime
axlog-->axruntime
axnet-->axruntime
axdisplay-->axruntime
axtask-->axruntime
axprocess-->axruntime
axtask-->axsync
axtask-->axprocess
axfs_os-->axprocess
axhal-->axprocess

axprocess-->axsyscall
axsyscall-->axruntime
axalloc-->axtask
axhal-->axtask
axconfig-->axtask
axlog-->axtask

axhal-->axmem
axalloc-->axmem

axmem-->axprocess

Pic from week10

Tasks

• Common
  • #44
• axprocess
  • axfs_os #46
  • axmem (WIP)
  • axtask
• ... Updates later

Hello, I am amazed by the redis running on arceos. This is fantastic work. However, I didn't see the hardware specifications for the benchmark in the README file under the apps/c/redis directory (it could also be that I overlooked it). I only saw that the tests were conducted under 2GB of memory size. Could you please provide additional details such as the specific CPU model, clock speed, and other relevant specifications?

$ make A=apps/c/helloworld ARCH=riscv64 run
.......
rust-lld -flavor gnu -nostdlib -static -no-pie --gc-sections -T/home/chyyuu/thecodes/arceos/modules/axhal/linker_riscv64.lds apps/c/helloworld/main.o ulib/c_libax/build_riscv64/libc.a target/riscv64gc-unknown-none-elf/release/liblibax.a -o apps/c/helloworld/helloworld_f
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(stat.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(time.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(stdlib.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(fcntl.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(string.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(stdio.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(mmap.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(unistd.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_riscv64/libc.a(assert.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(libax-99558854f9f72cb2.libax.8f06c8432ac99f28-cgu.0.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.0.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.1.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.10.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.11.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.12.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.13.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.14.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.15.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.2.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/riscv64gc-unknown-none-elf/release/liblibax.a(compiler_builtins-8c97496fd8e79463.compiler_builtins.5f3b8f588c381ca5-cgu.3.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
make: *** [ulib/c_libax/build.mk:74: apps/c/helloworld/helloworld_qemu-virt-riscv.elf] Error 1

$ make A=apps/c/helloworld ARCH=aarch64 run
......
rm -f ulib/c_libax/build_aarch64/libc.a
aarch64-linux-musl-ar rc ulib/c_libax/build_aarch64/libc.a ulib/c_libax/build_aarch64/stat.o ulib/c_libax/build_aarch64/time.o ulib/c_libax/build_aarch64/stdlib.o ulib/c_libax/build_aarch64/fcntl.o ulib/c_libax/build_aarch64/string.o ulib/c_libax/build_aarch64/stdio.o o
aarch64-linux-musl-ranlib ulib/c_libax/build_aarch64/libc.a
Linking apps/c/helloworld/helloworld_qemu-virt-aarch64.elf
rust-lld -flavor gnu -nostdlib -static -no-pie --gc-sections -T/home/chyyuu/thecodes/arceos/modules/axhal/linker_aarch64.lds apps/c/helloworld/main.o ulib/c_libax/build_aarch64/libc.a target/aarch64-unknown-none-softfloat/release/liblibax.a -o apps/c/helloworld/hellowof
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(stat.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(time.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(stdlib.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(fcntl.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(string.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(stdio.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(mmap.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(unistd.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: ulib/c_libax/build_aarch64/libc.a(assert.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(libax-3c217168e80c2c7b.libax.e636c8b0142bf204-cgu.1.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.0.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.1.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.10.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.11.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.12.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.13.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.14.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.15.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.2.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: target/aarch64-unknown-none-softfloat/release/liblibax.a(compiler_builtins-164467728415cd01.compiler_builtins.a3c2a0a8e451691c-cgu.3.rcgu.o) is incompatible with apps/c/helloworld/main.o
rust-lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
make: *** [ulib/c_libax/build.mk:74: apps/c/helloworld/helloworld_qemu-virt-aarch64.elf] Error 1

BUT x86_64 ARCH can build and run correctly.

Bug Description

In modules/axhal/linker.lds.S, the percpu area is linked by 64 Byte aligned:

    . = ALIGN(4K);
    _percpu_start = .;
    .percpu 0x0 : AT(_percpu_start) {
        _percpu_load_start = .;
        *(.percpu .percpu.*)
        _percpu_load_end = .;
        . = ALIGN(64);
        _percpu_size_aligned = .;

        . = _percpu_load_start + _percpu_size_aligned * %SMP%;
    }
    . = _percpu_start + SIZEOF(.percpu);
    _percpu_end = .;

    . = ALIGN(4K);
    _edata = .;

However, in function percpu_area_base in crates/percpu/src/imp.rs, the base address of percpu area for each core is aligned up to 4KB. Therefore, operations on the per-CPU area will overwrite the subsequent data segment. For example, the boot stack region.

const fn align_up(val: usize) -> usize {
    const PAGE_SIZE: usize = 0x1000;
    (val + PAGE_SIZE - 1) & !(PAGE_SIZE - 1)
}

/// Returns the base address of the per-CPU data area on the given CPU.
///
/// if `cpu_id` is 0, it returns the base address of all per-CPU data areas.
#[doc(cfg(not(feature = "sp-naive")))]
pub fn percpu_area_base(cpu_id: usize) -> usize {
    cfg_if::cfg_if! {
        if #[cfg(target_os = "none")] {
            extern "C" {
                fn _percpu_start();
            }
            let base = _percpu_start as usize;
        } else {
            let base = *PERCPU_AREA_BASE.get().unwrap();
        }
    }
    base + cpu_id * align_up(percpu_area_size())
}

This bug occurs when the size of the boot stack region is zero, as operations on the per-CPU area directly modify the subsequent BSS segment. Reading from the per-CPU area also reads some content from the BSS segment, leading to unpredictable errors. (Otherwise, modifications to the per-CPU area would affect the boot stack memory region. So far, no issues have arisen from altering the per-CPU area.)

Fix

1. modify the modules/axhal/linker.lds.S, make _percpu_size_aligned aligned by 4KB.
2. change the align_up in crates/percpu/src/imp.rs to aligned_up_64.

I look at the gen_offset in the crates/percpu_macros/src/arch.rs

pub fn gen_offset(symbol: &Ident) -> proc_macro2::TokenStream {
    quote! {
        let value: usize;
        unsafe {
            #[cfg(target_arch = "x86_64")]
            ::core::arch::asm!(
                "movabs {0}, offset {VAR}",
                out(reg) value,
                VAR = sym #symbol,
            );
            #[cfg(target_arch = "aarch64")]
            ::core::arch::asm!(
                "movz {0}, #:abs_g0_nc:{VAR}",
                out(reg) value,
                VAR = sym #symbol,
            );
            #[cfg(any(target_arch = "riscv32", target_arch = "riscv64"))]
            ::core::arch::asm!(
                "lui {0}, %hi({VAR})",
                "addi {0}, {0}, %lo({VAR})",
                out(reg) value,
                VAR = sym #symbol,
            );
        }
        value
    }
}

It seems like that the instruction MOVZ move only lower 16-bits of symbol into value.

Would it be possible to add it to the gen_offset as follows:

            #[cfg(target_arch = "aarch64")]
            ::core::arch::asm!(
                "movz {0}, #:abs_g0_nc:{VAR}",
                "movk {0}, #:abs_g1_nc:{VAR}",
                "movk {0}, #:abs_g2_nc:{VAR}",
                "movk {0}, #:abs_g3:{VAR}",
                out(reg) value,
                VAR = sym #symbol,
            );

Thanks!!!

Hi,
Show as the image, I ran the Display app on Ubuntu Server platform at first time, but it don't display any graphical interface. So I run it on Deepin Desktop platform later, and it also has same error. Why?
I have run all apps successfully so far except Display, Net and C apps. I guess the reason that I can't run the C apps successfully is also there aren't necessary libs from information what I get in error logs.
At last, by the way, I plan to check for mirror repository updates per day from GitHub repository and will sync from it if necessary.

Background Information: I was trying to develop arceos in nixos and nix environment to minimize the impact of the development environment on the native environment, for example $PATH.
What i have done: I have completed the rCore support, arceos is in the process.

The arceos flakes only completed partial adaptation at this stage, x86_64 haven't supported yet, riscv64 and aarch64 has past all user test. My current progress could be seen in flake branch, which contains some change in the original file. If you have any suggestions or ideas about the problem, I would be very grateful.

[translation]

背景资料：我试图在 nixos and nix 环境中配置arceos的开发环境，以最大限度地减少开发环境对本地环境的影响，对于$PATH。
我做了什么：我已经完成了rCore支持，arceos正在进行中。
arceos的flakes在这个阶段只完成了部分的适配，x86_64还没有支持，riscv 64和aarch 64目前通过了所有用户测试。
我的进度 可以在flake分支中看到，其中包含了对原文件的一些修改。如果你对这个问题有任何建议或想法，我将非常感激。

How could you synchronize my current progress (For nix user):

Current primary functionality is based on the devShells of nix flake, you should be able to open nix development environment though nix develop.
If there is any other error like experimental-feature, you should open /etc/nix/nix.conf add experimental-features=nix-commands flake to enable the experimental features.

Considers managing dependencies version in root Cargo.toml.

i.g.,

# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"

# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true

We can utilize this to avoid dependency version conflicts in the sub-crates.

See also, https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table

According to the description of the riscv spec H extension, the root directory page table size of the G-stage is 16KiB and aligned to 16KiB. However, the implementation of the arceos page table crate only provides a root directory page table size of 4KiB and can only create page tables using the try_new() method. I hope to implement a page table structure with a root directory size of 16KiB and inherit the arceos page table crate. Is there an elegant way to solve this issue?

I checked some async runtime crates and found the pasts. We can implement a minimal async runtime that only requires core::sync::AtomicBool and axstd::Thread. Would you have any suggestions for this idea?

It often causes CI to fail: https://github.com/rcore-os/arceos/actions/runs/5949567475/job/16135614481

Right now, I am designing percpu struct in hypercraft. When initializing SMP, I need to obtain information about all of cpu info, such as the number of hart, whether it supports AIA and SSTC, and so on. This information needs to be probed and parsed through device trees. However, these pieces of information are not actually part of the core content of the hypervisor. Is it necessary to add CPU probe information in ArceOS, just like https://github.com/rivosinc/salus/blob/main/drivers/src/cpu.rs#L34 ?