Unimplemented Syscalls

[rennergade]

There's been discussion that when compiling applications (coreutils, python etc) that they are using syscalls that we haven't implemented.

I believe this is due to the configure script. From some quick research:

configure generates short C programs that attempt to include specific headers and call the desired system calls. It then tries to compile these programs. If the compilation succeeds, the script concludes that the system call or feature is available.

I think the easiest way to fix this is to undefine unimplemented syscalls in libc.

[qianxichen233]

Yeah, this is one way to fix them. I think there might be a huge amount of syscalls in glibc (probably around 300-400), so finding the glibc entries for these syscalls and undefine them might take some time because there isn't an universal folder that just hold all the syscall files, many syscalls files are seperated into different locations and we need to find them first.
Besides, I think there are also syscalls that are just variants of syscalls that we already support (e.g. dup3 syscall). For I guess we also need to filter out all the possible variants of syscalls that we can support and support them as well?

[qianxichen233]

And I also think there should be many non-syscall functions in glibc are using these unimplemented syscalls as well. So if we just undefine the syscalls, we also need to recursively undefine(or comment out) all functions that used these syscalls as well.

[Yaxuan-w]

because there isn't an universal folder that just hold all the syscall files, many syscalls files are seperated into different locations and we need to find them first.

Agreed. Also some syscalls are implemented inside the variant syscall (eg: readlinkat/readlink). So finding the variances might be more efficient

[rennergade]

That makes sense.

It may be useful to take a look at what macros already exist in libc, and why we see these pop up in lind-wasm vs lind-nacl. For example someone mentioned dup3 which hadn't shown up in lind-nacl compilations. It seems like there is a __USE_GNU macro that toggles whether that syscall is implemented.

There's probably a few macro defines differing between the two platforms producing different compilation results, and just getting those to match would probably simplify the development process.