Analysis for the improvement of libctest

[y3none]

First, in order to pass the tests on both the x86 and aarch architectures, it is necessary to add TLS-related processing in ArceOS and use new_task.ctx_mut().set_tls(axhal::arch::read_thread_pointer().into()); in Starry's clone_task to set the TLS：

tls function:

/// Gets the TLS area.
pub fn tls(&self) -> VirtAddr {
    VirtAddr::from(self.fs_base)
}

The function is used to obtain the virtual address of the TLS area of the current task. It retrieves the stored address value of the TLS area from the fs_base field of the TaskContext structure and converts it to the VirtAddr type for return. The fs_base field is used to store the base address of the TLS area, and this function provides a way to access this address.

set_tls function:

/// Sets the TLS area.
pub fn set_tls(&mut self, tls_area: VirtAddr) {
    self.fs_base = tls_area.as_usize();
}

This function is used to set the address of the TLS area of the current task. It takes a parameter tls_area of type VirtAddr, which represents the virtual address of the TLS area to be set. Then it converts this address to the usize type and stores it in the fs_base field of the TaskContext structure.

Role in the TaskContext structure:

The TaskContext structure is used to save the hardware state of a task, including the kernel stack top address (kstack_top), stack pointer (rsp), and the base address of the TLS area (fs_base). The tls and set_tls functions are closely related to the fs_base field, providing read and write operations for the address of the TLS area, which facilitates the handling of TLS-related information when managing the task context.

Role in context switching:

In the switch_to function, when performing task context switching, the handling of the TLS area is involved:

#[cfg(any(feature = "tls", feature = "uspace"))]
unsafe {
    self.fs_base = super::read_thread_pointer();
    super::write_thread_pointer(next_ctx.fs_base);
}

Here, the fs_base of the current task is first saved (by reading the TLS pointer of the current thread through the read_thread_pointer function), and then the fs_base of the next task is written (by setting the TLS pointer of the thread through the write_thread_pointer function). The tls and set_tls functions provide the basis for saving and restoring the TLS area, ensuring that the TLS area information of each task can be correctly transferred and restored during the context switching process.

Relationship with other modules and functions:

The TLS area is usually used to store thread-specific data, such as thread-local variables and caches. These two functions may have potential associations with structures such as UspaceContext and TrapFrame, as well as functions like enter_uspace. For example, when entering user space (in the enter_uspace function), it may be necessary to correctly set and use the TLS area. The tls and set_tls functions provide interfaces for operating the address of the TLS area, which helps maintain the TLS-related state during the switching of different tasks and spaces.

In summary, the tls and set_tls functions in the entire framework are mainly responsible for managing the address of the task's TLS area, providing read and write functions for the TLS area for context switching and other operations related to task states, ensuring that the thread-local storage-related information can be correctly handled during task execution and switching.

Analysis of Wingrew's code modifications:

After completing the above adaptations for x86 and aarch, Wingrew mainly adapted the main function part of src/main.rs for the competition evaluation, that is, the following part:

#[unsafe(no_mangle)]
fn main() {
    println!("#### OS COMP TEST GROUP START basic-glibc ####");
    println!("#### OS COMP TEST GROUP START basic-musl ####");
    let testcases = option_env!("AX_TESTCASES_LIST")
       .unwrap_or_else(|| "Please specify the testcases list by making user_apps")
       .split(',')
       .filter(|&x| !x.is_empty());
    let mut i = 0;
    for testcase in testcases {
        let args = testcase
           .split_ascii_whitespace()
           .map(ToString::to_string)
           .collect::<Vec<_>>();
        let exit_code = run_user_app(&args, &[]);
        info!("User task {} exited with code: {:?}", testcase, exit_code);
        i += 1;
        if i == 32{
            println!("#### OS COMP TEST GROUP END basic-musl ####");
            println!("#### OS COMP TEST GROUP END basic-glibc ####");
            println!("#### OS COMP TEST GROUP START libctest-glibc ####");
            println!("#### OS COMP TEST GROUP START libctest-musl ####");
        }else if i == 161{
            println!("#### OS COMP TEST GROUP END libctest-musl ####");
            println!("#### OS COMP TEST GROUP END libctest-glibc ####");
        }
    }
}

• Print the start information of the test groups.
• Obtain the test case list from the environment variable AX_TESTCASES_LIST, split it, and filter out empty strings.
• Iterate through the test case list, parse the parameters of each test case into a vector of strings, call the run_user_app function to run the user task, and record the exit code of the task.
• According to the serial number of the test case, print the start and end information of different test groups.

In this way, the test outputs for 32 basic test cases and 131 libc test cases can be completed.

In addition, before reading Wingrew's modifications, I first referred to BattiestStone4's testing method. In oscomp, BattiestStone4 created testcase_list_musl_libctest and testcase_list_glibc_libctest by imitating testcase_list and added relevant definitions in the Makefile for testing. In this way, there is no need to count in the main function, and the libc tests can be carried out by repeating the operations for the basic tests:

fn main() {
    println!("#### OS COMP TEST GROUP START basic-glibc ####");
    println!("#### OS COMP TEST GROUP START basic-musl ####");
    let testcases = option_env!("AX_TESTCASES_LIST")
        .unwrap_or_else(|| "Please specify the testcases list by making user_apps")
        .split(',')
        .filter(|&x| !x.is_empty());
 
    for testcase in testcases {
        let args = testcase
            .split_ascii_whitespace()
            .map(ToString::to_string)
            .collect::<Vec<_>>();
 
        let exit_code = run_user_app(&args, &[]);
        info!("User task {} exited with code: {:?}", testcase, exit_code);
    }
    println!("#### OS COMP TEST GROUP END basic-musl ####");
    println!("#### OS COMP TEST GROUP END basic-glibc ####");
 
    println!("#### OS COMP TEST GROUP START libctest-glibc ####");
    println!("#### OS COMP TEST GROUP START libctest-musl ####");
    let testcases = option_env!("AX_MUSL_LIBCTEST_TESTCASES_LIST")
        .unwrap_or_else(|| "Please specify the testcases list by making user_apps")
        .split(',')
        .filter(|&x| !x.is_empty());
 
    for testcase in testcases {
        let args = testcase
            .split_ascii_whitespace()
            .map(ToString::to_string)
            .collect::<Vec<_>>();
 
        let exit_code = run_user_app(&args, &[]);
        info!("User task {} exited with code: {:?}", testcase, exit_code);
    }
    println!("#### OS COMP TEST GROUP END libctest-musl ####");
    println!("#### OS COMP TEST GROUP END libctest-glibc ####");
}

For Chinese version, see this.