Support for more syscalls

[Azure-stars]

This issue is used to store various records in the process of supporting syscall, including new features, existing bugs and fixes, etc.

Please submit feature or bug feedback in the following format:

Related syscalls

{syscall_name}

Type

bug/new feature/any other

Details

xxx

You can attach a picture here.

[Azure-stars]

An example belike

Related syscalls

• fstat

Type

new feature

Details

This commit implement the fstat syscall.(For reference only, not real situation)

[BattiestStone4]

Related syscalls

• clone
• mmap

Type

Bug with clone in loongarch64

Details

I am trying to fix bugs with clone syscall in loongarch64. So far I have found out error in clone_or_err, when query page table with heap base address, self.read() returns Err(BadAddress).

AddrSpace when error happens. Notice that mmap syscall is called twice, and 2nd call mmap heap base address again, leading to the mistake in querying pagetable.

From Ressed's document, he said that the problem can be fixed when changing heap base address to 0x0 in main.rs. Test shows that when changing heap base address to 0, the 2nd call will mmap 0x0, and it will return Err(EINVAL). This certainly will not affect heap space which is mapped before, but it isn't approaching the problem from its source.

Running testcase again in riscv, and mmap is only called once.

I think that's the problem. If it can be fixed, bugs in clone can be fixed too. However I need some inspiration for this problem. Looking forward to reply and guidance.

[AsakuraMizu]

So far I have found out error in clone_or_err, when query page table with heap base address, self.read() returns Err(BadAddress).

Seems that this error is related to oscomp/arceos#4. Maybe you can try to update arceos base repository and check if this fixes the issue?

[BattiestStone4]

Seems that this error is related to oscomp/arceos#4. Maybe you can try to update arceos base repository and check if this fixes the issue?

That works. Thanks!

[BattiestStone4]

Related syscalls

• select

Type

Bug with select in x86_64

Details

I am trying to suit for iozone with starry-next, and now i have met a problem with sys_select.

This syscall falls into loop, leading iozone testcase fails to continue running, and all the arguments of sys_select are zero, which is not normal for the syscall.

I think maybe that relates to FD_TABLE? Since the arguments of this syscall are strongly related with file descriptors, but I can't find a proper way to check whether it is caused by other syscall or not. Looking forward to help.