syscall: audit missing syscalls on linux/arm64

[minux]

Despite our efforts, it seems there are still syscalls in the syscall
package that are missing on linux/arm64.

Getpgrp is one.

[suihkulokki]

At least the following deprecated syscalls still need wrappers for arm64:
epoll_create -> epoll_create1
epoll_wait -> epoll_pwait
futimesat -> utimensat
getpgrp -> getpgid
pause -> ?
time -> gettimeofday?
ustat -> statfs
utime -> utimes

There are also some syscalls in the unimplemented table that need to be taken care when implemented:

evenfd -> eventfd2
signalfd -> signalfd4
poll -> ppoll

[suihkulokki]

looking at glibc, pause is implemented as
sigset_t set;
rt_sigprocmask(SIG_BLOCK, NULL, &set, 8) = 0
rt_sigsuspend(&set, 8

and time is implemented as gettimeofday from the vdso. - which is how go seems to do Time on amd64 as well.

[suihkulokki]

And dup2 -> dup3 wrapper needed (see #11981)

[suihkulokki]

Any way to make this less unplanned? I keep bumping into go packages that naively call syscalls not being aware they have been deprecated and are not available on arm64..

cc @davecheney and @4ad

[bradfitz]

@suihkulokki, which? Those packagess are buggy, then. Using syscall is like using unsafe... you have to really know what you're doing. They probably don't run well on Windows or Plan 9 or Solaris either.

[suihkulokki]

@bradfitz This is typically linux-specific code, such as some of the libraries used by docker (example: libcontainer) or code where linux implementation is in a different file then windows one (fsnotify). Both examples have now fixes commited, but I expect that more are being created as we talk. Developers are not aware that bunch of syscalls go provides are actually deprecated ones, because they work just fine on amd64. My faith that people who use the syscall package know what they are doing is not very strong...

[4ad]

My faith that people who use the syscall package know what they are doing is not very strong

People that use the syscall package (and unsafe, as already mentioned) should know what they are doing.

It's not clear to me why we should cater to poorly-written programs, thereby decreasing their incentive to move to the go.sys package even more.

[suihkulokki]

It's not clear to me why we should cater to poorly-written programs, thereby decreasing their incentive to move to the go.sys package even more.

Ok, I didn't know about go.sys. However, the same problems are there too. People who need Epoll will use EpollCreate() instead of EpollCreate1() because nothing hints that the former is deprecated. We can:

1. whenever a arm64 user compiles the affected code, send a patch upstream to change it

• this is the current somewhat inconvenient state
  2) add a EpollCreate -> EpollCreate1 wrapper to go.sys
• this is the "cater poorly written programs choice"
  3) remove legacy syscalls like EpollCreate from go.sys
• this breaks backward compatibility

I would assume 2, is preferred choice, since the current arm64 has a bunch already, example:

https://github.com/golang/sys/blob/master/unix/syscall_linux_arm64.go#L132