1 files changed, 0 insertions, 53 deletions
diff --git a/results/classifier/zero-shot-user-mode/output/instruction/2485 b/results/classifier/zero-shot-user-mode/output/instruction/2485
deleted file mode 100644
index 01431ab6..00000000
--- a/results/classifier/zero-shot-user-mode/output/instruction/2485
+++ /dev/null
@@ -1,53 +0,0 @@
-instruction: 0.552
-runtime: 0.306
-syscall: 0.143
-
-
-
-getifaddrs linked with musl libc hangs on big-endian targets
-Description of problem:
-When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success.
-
-```c
-#include <stdlib.h>
-#include <ifaddrs.h>
-
-int
-main (void)
-{
-
-    struct ifaddrs *ifa = 0;
-    int error;
-
-    error = getifaddrs(&ifa);
-    if (error || !ifa)
-        exit(1);
-    else
-        exit(0);
-
-    return 0;
-}
-```
-Steps to reproduce:
-1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/))
-2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`)
-3. Observe that the process hangs.
-Additional information:
-This has come up elsewhere:
-
-* https://bugs.gentoo.org/914256
-* https://www.openwall.com/lists/musl/2018/05/30/4
-* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain)
-* Likely affects sparc but that port/toolchain is also a WIP
-
-Here are some static sample binaries for the above program:
-
-* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later)
-
-GitLab labels seem to be missing:
-
-* ~"kind::Bug"
-* ~"linux-user"
-* ~"target: ppc"
-* ~"target: m68k"
-* ~"target: s390x"