Change https://golang.org/cl/353392 mentions this issue: unix: skip TestSysvSharedMemory on ENOSYS

Change https://golang.org/cl/353398 mentions this issue: unix: SysvShmCtl use ipc_64 on mips64

I believe the combination of 353392 and 353398 should address the test failures. However, I don't really understand the IPC_64 thing in 353398... if there was someone else who understood linux syscalls a bit better then a better fix could be made.

I am a bit surprised that the tests didn't fail on my original commit in gerrit, but I assume it was just that it didn't run on all the architectures? I do think I've identified what's going on here now, and I'll push a better fix soon I hope.

After Linux 5.1, a bunch of architectures got SYS_SHMxxx syscalls (torvalds/linux@0d6040d). However, prior to that they only supported using the SYS_IPC entrypoint. Looking through glibc's source, it doesn't bother trying to detect this at compile time, instead there are two different macros __ASSUME_SYSVIPC_DEFAULT_IPC_64 and __ASSUME_DIRECT_SYSVIPC_SYSCALLS that are defined in architecture specific configuration files (kernel-features.h).

In sysdeps/unix/sysv/linux/ipc_priv.h there is this:

#ifdef __ASSUME_SYSVIPC_DEFAULT_IPC_64
# define __IPC_64      0x0
#else
# define __IPC_64      0x100
#endif

And in glibc/sysdeps/unix/sysv/linux/kernel-features.h this is defined:

/* The generic default __IPC_64 value is 0x0, however some architectures
   require a different value of 0x100.  */
#define __ASSUME_SYSVIPC_DEFAULT_IPC_64		1

It appears that __ASSUME_SYSVIPC_DEFAULT_IPC_64 is #undef for these architectures/conditions:

• alpha
• arm
• i386 (if __LINUX_KERNEL_VERSION < 0x050100)
• microblaze
• mips (if _MIPS_SIM == _ABIO32 && __LINUX_KERNEL_VERSION < 0x050100)
• ppc (if __LINUX_KERNEL_VERSION < 0x050100)
• s390 (if __LINUX_KERNEL_VERSION < 0x050100)
• sh4 (if __LINUX_KERNEL_VERSION < 0x050100)
• sparc (if __LINUX_KERNEL_VERSION < 0x050100)

__ASSUME_DIRECT_SYSVIPC_SYSCALLS is often disabled as well under similar conditions.

I believe the combination of 353392 and 353398 should address the test failures.

Looks like the builder failures have indeed cleared.