[libc-commits] [libc] [libc] check a few syscall #'s to avoid wrong syscalls (PR #123100)

[Nick Desaulniers via libc-commits]

================
@@ -0,0 +1,44 @@
+//===-------------- Simple checks for cross compilation -------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_LIBC_SRC___SUPPORT_OSUTIL_LINUX_CROSS_COMPILE_CLIPPY_H
+#define LLVM_LIBC_SRC___SUPPORT_OSUTIL_LINUX_CROSS_COMPILE_CLIPPY_H
+
+#include "src/__support/macros/properties/architectures.h"
+#include <sys/syscall.h>
+
+#define MSG                                                                    \
+  "Looks like you may be using the host kernel headers to cross "              \
+  "compile. This is bad because the syscall numbers frequently (but not "      \
+  "always) differ between architectures.  What frequently happens as a "       \
+  "result are crashes in startup."
+
+// https://github.com/hrw/syscalls-table is super helpful for trying to find
+// syscalls with unique numbers.
+
+#ifdef LIBC_TARGET_ARCH_IS_AARCH64
+static_assert(__NR_renameat == 38, MSG);
+#elif defined(LIBC_TARGET_ARCH_IS_ARM)
+static_assert(__NR_renameat == 329, MSG);
+#elif defined(LIBC_TARGET_ARCH_IS_X86_32)
+static_assert(__NR_renameat == 302, MSG);
+#elif defined(LIBC_TARGET_ARCH_IS_X86_64)
+static_assert(__NR_renameat == 264, MSG);
+#elif defined(LIBC_TARGET_ARCH_IS_RISCV64)
+static_assert(__NR_riscv_flush_icache == 259, MSG);
+static_assert(__NR_renameat2 == 276, MSG);
+#elif defined(LIBC_TARGET_ARCH_IS_RISCV32)
+static_assert(__NR_riscv_flush_icache == 259, MSG);
+#ifdef __NR_iodestroy
+#error MSG
----------------
nickdesaulniers wrote:

Yeah, I guess mixing preprocessor errors with `static_assert` is inconsistent.  We should be able to check all of these via preprocessor.

```c
#if (__NR_riscv_flush_icache) != 259
#error MSG
#endif
```
---

If you question was specifically about `__NR_iodestroy`, the issue is that riscv32 and riscv64 have nearly the same syscall numbers (and riscv64 is pretty close to aarch64, too, given how modern those architectures are to the rest).  riscv32 is missing a few syscalls, though, so that's what this particular check is doing.  It's possible they add them in the future, so this check is brittle, but perhaps they may not.   I don't think glibc has a wrapper for `iodestroy` (and don't know much about that syscall in particular off the top of my head), but lack of glibc wrapper makes me think that this isn't a popular syscall (but iirc iouring still doesn't despite its popularity, and rseq only recently got glibc wrappers).

https://github.com/llvm/llvm-project/pull/123100