Skip to content

Use correct types for syscalls #19559

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

kleisauke
Copy link
Collaborator

Split from: #13007.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the tests pass then LGTM.

IIRC there was a reason we did it this way when porting the musl syscall layer, but I can't remember exactly what that was.. so lets just go with this if the tests pass.

return g_pid;
}

weak int __syscall_getppid() {
weak pid_t __syscall_getppid() {
return g_ppid;
}

weak int __syscall_linkat(int olddirfd, intptr_t oldpath, int newdirfd, intptr_t newpath, int flags) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also use pointer types here for oldpath/newpath? and elsewhere?

return g_ppid;
}

weak int __syscall_linkat(int olddirfd, intptr_t oldpath, int newdirfd, intptr_t newpath, int flags) {
return -EMLINK; // no hardlinks for us
}

weak int __syscall_getgroups32(int size, intptr_t list) {
if (size < 1) {
weak int __syscall_getgroups32(int count, intptr_t list) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should list be gid_t* (avoiding the case below?)

if (internal_fstat(fd, &st))
return -1;
return (uptr)st.st_size;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these new functions needed?

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we avoid the all the changes/additions to the sanitizers? This change seems a lot more risky once you add those in?

Also changing the socket syscalls to be varargs seems a little out of scope and perhaps separable.

int __syscall_chmod(intptr_t path, int mode);
int __syscall_getpid(void);
typedef unsigned socklen_t;
typedef unsigned long nfds_t;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicating these definitions here seems a little sad.

@kleisauke
Copy link
Collaborator Author

Let me mark this as a draft, there are many more changes needed than expected. For example, doing this:

-int __syscall_openat(int dirfd, intptr_t path, int flags, ...); // mode is optional
+int __syscall_openat(int dirfd, const char *path, int flags, ...); // mode is optional

Will fail within the sanitizers (which uses the internal syscall function of musl):

return internal_syscall(SYSCALL(openat), AT_FDCWD, (uptr)filename, flags);

class libsanitizer_common_rt(CompilerRTLibrary, MTLibrary):
name = 'libsanitizer_common_rt'
# TODO(sbc): We should not need musl-internal headers here.
includes = ['system/lib/libc/musl/src/internal',

Details
/home/kleisauke/emscripten/system/lib/compiler-rt/lib/sanitizer_common/sanitizer_syscall_generic.inc:17:24: note: expanded from macro 'SYSCALL'
   17 | # define SYSCALL(name) SYS_ ## name
      |                        ^~~~~~~~~~~~
<scratch space>:132:1: note: expanded from here
  132 | SYS_openat
      | ^~~~~~~~~~
/home/kleisauke/emscripten/cache/sysroot/include/bits/syscall.h:61:21: note: expanded from macro 'SYS_openat'
   61 | #define SYS_openat              __syscall_openat
      |                                 ^~~~~~~~~~~~~~~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/kleisauke/emscripten/system/lib/libc/musl/src/internal/syscall.h:65:80: note: expanded from macro '__SYSCALL_DISP'
   65 | #define __SYSCALL_DISP(b,...) __SYSCALL_CONCAT(b,__SYSCALL_NARGS(__VA_ARGS__))(__VA_ARGS__)
      |                                                                                ^~~~~~~~~~~
/home/kleisauke/emscripten/system/lib/libc/musl/src/internal/syscall.h:55:61: note: expanded from macro '__syscall_emscripten3'
   55 | #define __syscall_emscripten3(n,a,b,c) __syscall_emscripten(n,__scc(a),__scc(b),__scc(c))
      |                                                             ^
/home/kleisauke/emscripten/system/lib/libc/musl/src/internal/syscall.h:51:38: note: expanded from macro '__syscall_emscripten'
   51 | #define __syscall_emscripten(n, ...) n(__VA_ARGS__)
      |                                      ^
/home/kleisauke/emscripten/cache/sysroot/include/syscall_arch.h:93:5: note: candidate function not viable: no known conversion from 'uptr' (aka 'unsigned long') to 'const char *' for 2nd argument
   93 | int __syscall_openat(int dirfd, const char *path, int flags, ...); // mode is optional
      |     ^
/home/kleisauke/emscripten/system/lib/compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:270:27: error: no matching function for call to '__syscall_openat'
  270 |   return internal_syscall(SYSCALL(openat), AT_FDCWD, (uptr)filename, flags,

The solution is to rework the sanitizers to avoid musl's syscall layer, similar to the NetBSD and macOS implementations.

uptr internal_open(const char *filename, int flags) {
return open(filename, flags);
}

@kleisauke kleisauke marked this pull request as draft June 9, 2023 15:54
@sbc100
Copy link
Collaborator

sbc100 commented Jun 9, 2023

Yeah I think this is one reason things are the way they today.. to allow the SYSCALL stuff to work.

Perhaps we could land the initial/smaller version of this change that doesn't cause some much churn?

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

Successfully merging this pull request may close these issues.

2 participants