Okay, so I need to classify this bug report into one of the given categories: instruction, syscall, or runtime. Let's break it down step by step. The user is experiencing issues when running GCC tests under qemu-aarch64. The problem seems to be related to signal handling, specifically a segmentation fault and infinite loops in certain test cases. They noticed that the sizes of siginfo structures between the Linux kernel and QEMU differ: 136 vs. 128 bytes. The user identified that the issue arises from an incorrect definition of TARGET_SI_PAD_SIZE in QEMU's syscall_defs.h. In the kernel, this is calculated as (SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) divided by sizeof(int), which for Aarch64 is 4 * sizeof(int). So the padding size would be adjusted accordingly to fit within SI_MAX_SIZE. In contrast, QEMU currently defines TARGET_SI_PAD_SIZE as (TARGET_SI_MAX_SIZE / sizeof(int)) - 3. This leads to a larger pad than necessary because it doesn't account for the preambles correctly, causing the structures to be misaligned and mismatched between host and target. This seems to affect how signals are handled when running user space applications under QEMU. Since it's about handling signals, which involves system calls (like sigreturn or rt_sigreturn), I think this falls under a syscall issue because the problem occurs during signal processing, which relies on syscalls for communication between userland and the kernel. So, putting it all together, the bug is related to how QEMU handles system calls involving signal information structures. The incorrect padding size leads to ABI incompatibility, causing segmentation faults when applications try to use these signals. Therefore, this should be classified under 'syscall'. The issue stems from a miscalculation of the pad size for siginfo structures in QEMU's syscall handling, leading to an ABI mismatch with the Linux kernel. This affects signal processing and is related to system calls. syscalls