Okay, I'm looking at this bug report where someone is trying to build QEMU version 2.8.0 using a GCC cross-compiler for aarch64. They've encountered an error during the build process. Let me try to figure out what's going on here. The error message says that '__NR_signalfd' is undeclared in the function 'qemu_signalfd'. The code is trying to call syscall(SYS_signalfd, -1, mask, _NSIG / 8); but it can't find __NR_signalfd. This suggests that there's an issue with how the signalfd system call is being handled on the target architecture. The user configured QEMU with --target-list=x86_64-linux-user and specified aarch64 as the CPU. So they're building for x86_64 but using AArch64 instructions, which might be part of their cross-compilation setup. I remember that system call numbers can vary between architectures. '__NR_signalfd' is specific to certain architectures. Maybe on x86_64, the signalfd syscall has a different number or isn't available in the same way as on other architectures like arm64. Looking at QEMU's source code, especially the compatfd.c file, it seems that they're trying to provide compatibility for the signalfd system call across different targets. If the target (x86_64) doesn't define __NR_signalfd, then including this header would fail because the macro isn't defined. In this case, the problem is that when building for x86_64, the code expects __NR_signalfd to be available, but it's not. The error is occurring during compilation, so it's a build-time issue related to the headers or defines not being set correctly for the target architecture. I think this falls under the 'mistranslation' category because it involves incorrect mapping from the source (x86_64) to the target (aarch64) in terms of system call numbers and their availability. The code assumes that __NR_signalfd is present, which isn't the case for x86_64. mistranslation