Okay, so I'm trying to figure out how to classify this bug report related to qemu-aarch64 hanging after an upgrade of libc6. Let's break it down step by step. First, from the description, when someone runs `cargo test` using `qemu-aarch64`, the process hangs with 100% CPU usage and doesn't respond to a Ctrl-C interrupt via GDB. This happens specifically after upgrading libc6 to version 2.36-9+deb12u6. It's important that the same binary runs fine on a real arm64 target with this upgraded libc, which suggests it's not an issue with the binary itself but something related to how QEMU is handling things. The steps to reproduce involve setting up a Rust project with a simple test, configuring the `.cargo/config.toml` to use `qemu-aarch64` as the runner. The problem occurs when running tests in this setup. Looking at possible categories: instruction, syscall, runtime. - **Instruction:** This would relate to a specific CPU instruction causing issues. But since it's hanging and not crashing with an error related to an unknown instruction, I don't think that's the case here. - **Syscall:** Could be related to how system calls are handled by QEMU. The upgrade in libc might change how syscalls are made or handled, potentially causing a deadlock or infinite loop in QEMU when emulating the environment. - **Runtime:** This is a broader category for other runtime errors not covered by instructions or syscalls. Since it's about the emulator hanging and high CPU usage, this could fall under runtime issues because it's how QEMU manages execution during testing. But considering that the issue arises with the upgraded libc version, which affects system calls, perhaps it's more specific to how QEMU handles certain syscalls when interacting with the new library. The fact that GDB can't interrupt suggests there might be a problem in handling signals or interrupts within QEMU, possibly related to how it processes syscalls. So I'm leaning towards **syscall** because the issue seems tied to how system calls are being handled after the libc upgrade, causing QEMU to get stuck. syscall