gitlab scraper: download in toml and text format

28 files changed, 666 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314
new file mode 100644
index 000000000..174b4a8d2
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1314
@@ -0,0 +1,40 @@
+68k: issues with fremx and fmodx
+Description of problem:
+Some of the mac68k folks have been testing my MacOS branch at https://github.com/mcayland/qemu/tree/q800.upstream2-vm and noticed problems with the values of some of the MacOS _Pack5 transcendental functions. This is easily visible when calling the `sin()` and `cos()` functions whereby some angle ranges use the values from the wrong section of the waveform and/or return values with the incorrect sign.
+
+SolraBizna was kind enough to write a 68K MacOS test program to generate a sine table (including dumping the hex values of the FP registers) that could be run on real hardware for comparison with QEMU. Using this it was discovered that the issue is related to the implementation of the `fremx` and `fmodx` instructions which can be found in [`floatx80_modrem()`](https://gitlab.com/qemu-project/qemu/-/blob/master/fpu/softfloat.c#L2601).
+
+I have taken the output of the test program run on a real 68040 Mac and used it to create a test harness at https://github.com/mcayland/qemu/commits/68k-fmodrem-bug [(diff from git master)](https://github.com/mcayland/qemu/commit/4afd6b7c3cad89df943ec43395f95dad7f368338.diff) which iterates over 100 points of the sine table and uses the registers to indicate any failures according to the following comment:
+
+```
+    /*
+     * The test program below hangs when it completes and the exit
+     * condition can be determined using the monitor via "info
+     * registers" command as follows:
+     *
+     *     D7 is the test number (0-99)
+     *     D6 is the error code
+     *         0 = no error
+     *         1 = frem result incorrect
+     *         2 = frem fpsr result incorrect
+     *         3 = fmod result incorrect
+     *         4 = fmod fpsr result incorrect
+     *     D2 is the actual result of the long comparison
+     *     D1 is the expected result of the long comparison
+     *
+     * A successful termination of the test program is when D7 == 100
+     * and D6 == 0.
+     */
+```
+
+This enables the majority of debugging to be done directly using `info registers` in the monitor rather than manually stepping through the example code using the gdbstub.
+
+Based upon my local testing on `qemu-system-m68k` there are 2 main differences between QEMU and the output from a real 68040:
+
+- Differences in precision
+
+The very first `fremx` result comparison fails here returning `0x3ffe0000 0xc90fdaa2 0x2168c23c 0x........` instead of `0x3ffe0000 0xc90fdaa2 0x2168c238 0x........`. Fortunately the difference in precision is small, and while it may not be possible to fix this, at least it gives a measure of how QEMU's emulation compares to a real 68040.
+
+- Incorrect setting of the quotient byte
+
+Bits 16-23 of the FPSR are supposed to contain the sign and 7 LSBs of the quotient for `fremx` and `fmodx` instructions, which is used in _Pack5 to generate an offset into a lookup table for the transcendental functions. It appears that the main cause of the incorrect `sin()` and `cos()` functions is due to the quotient byte being set incorrectly by `fremx`, causing MacOS to jump to the wrong segment of the lookup table for certain angle ranges.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462
new file mode 100644
index 000000000..478cfcd05
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1462
@@ -0,0 +1,14 @@
+qemu-system-m68k segfaults on opcode 0x4848
+Description of problem:
+Running an m68k executable with opcode 0x4848 will segfault qemu-system-m68k
+Steps to reproduce:
+1. Boot m68k debian
+2. Compile program (see above for the oops.c source) that executes opcode 0x4848
+3. Run program
+4. QEMU segfaults:
+
+```
+./debian-m68k.sh: line 10:  4420 Segmentation fault      (core dumped) qemu-system-m68k -boot c -M q800 -serial none -serial mon:stdio -m 1000M -net nic,model=dp83932,addr=08:00:07:12:34:89 -net user -append "root=/dev/sda2 rw console=ttyS0 console=tty" -kernel virt/vmlinux-4.16.0-1-m68k -initrd virt/initrd.img-4.16.0-1-m68k -drive file=virt/debian-m68k-deb10.qcow2,format=qcow2 -nographic
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502
new file mode 100644
index 000000000..be35035a5
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1502
@@ -0,0 +1 @@
+Usermode qemu-m68k futex crash while running "cmake -E cmake_autogen"
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568
new file mode 100644
index 000000000..30b27fa4e
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1568
@@ -0,0 +1,39 @@
+qemu-system-m68k fails whenever the option "-d cpu_reset" is specified
+Description of problem:
+When specifying the option "-d cpu_reset", the following output is generated, and QEMU eventually crashes with a Segmentation fault:
+```
+CPU Reset (CPU 0)
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+...
+D0 = 00000000   A0 = 00000000   F0 = 0000 0000000000000000  (           0)
+D1 = 00000000   A1 = 00000000   F1 = 0000 0000000000000000  (           0)
+D2 = 00000000   A2 = 00000000   F2 = 0000 0000000000000000  (           0)
+D3 = 00000000   A3 = 00000000   F3 = 0000 0000000000000000  (           0)
+D4 = 00000000   A4 = 00000000   F4 = 0000 0000000000000000  (           0)
+D5 = 00000000   A5 = 00000000   F5 = 0000 0000000000000000  (           0)
+D6 = 00000000   A6 = 00000000   F6 = 0000 0000000000000000  (           0)
+D7 = 00000000   A7 = 00000000   F7 = 0000 0000000000000000  (           0)
+PC = 00000000   qemu: fatal: Bad CC_OP 0
+Segmentation fault (core dumped)
+```
+This also happens with the other m68k machine types.
+Steps to reproduce:
+1. Run QEMU with the given command line.
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831
new file mode 100644
index 000000000..8d4ec9e1b
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/1831
@@ -0,0 +1 @@
+qemu-system-m68k: ../hw/scsi/scsi-disk.c:557: scsi_write_data: Assertion `r->req.aiocb == NULL' failed.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000
new file mode 100644
index 000000000..1d919b7f5
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2000
@@ -0,0 +1,45 @@
+m68k: error "fatal: Unimplemented control register write 0x0 = 0x1"
+Description of problem:
+An attempt to run the NetBSD m68k kernel under QEMU crashes.
+The error message is:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+```
+Steps to reproduce:
+1. ```wget http://cdn.netbsd.org/pub/NetBSD/iso/9.3/NetBSD-9.3-mac68k.iso```
+2. Pull kernel out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop /home/bruno/vms/os-install-media/NetBSD-9.3-mac68k.iso /mnt
+cp /mnt/mac68k/binary/kernel/netbsd-GENERIC.gz .
+sudo umount /mnt
+chmod u+w netbsd-GENERIC.gz
+gunzip netbsd-GENERIC.gz
+```
+3. ```qemu-img create -f qcow2 netbsd93.qcow2 10G```
+4. ```qemu-system-m68k -m 256 -drive file=netbsd93.qcow2,format=qcow2,index=0 -nographic -kernel netbsd-GENERIC -cdrom NetBSD-9.3-mac68k.iso```
+
+It crashes like this:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+
+D0 = 00000001   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00330346   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00002e14   SR = 2700 T:0 I:7 SI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000 ->A7(USP) = 00330346   A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+Aborted (core dumped)
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091
new file mode 100644
index 000000000..215ce2773
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2091
@@ -0,0 +1,3 @@
+m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093
new file mode 100644
index 000000000..53cd67b38
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2093
@@ -0,0 +1,3 @@
+m68k: virt: Add command to virt-ctrl device to pause cpu until an interrupt happens
+Additional information:
+I'm working on how to implement this myself. Any hints would be great.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164
new file mode 100644
index 000000000..768ce63b6
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2164
@@ -0,0 +1,7 @@
+m68k: 68010 exception format is incorrect
+Description of problem:
+The exception format for the original 68000 is different to the 68010 and QEMU uses the incorrect format for 68010.
+Steps to reproduce:
+You need to have something that depends on the stack layout (i.e. nommu linux) to notice it.
+Additional information:
+I have posted a patch to fix it already: https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg02800.html
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165
new file mode 100644
index 000000000..27276236c
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2165
@@ -0,0 +1,68 @@
+m68k: 68000 strict alignment requirements not emulated correctly
+Description of problem:
+Unaligned accesses should cause an address error on the 68000 but apparently currently don't.
+Steps to reproduce:
+1. Create a 68000 based QEMU machine to port u-boot/linux
+2. Get u-boot/linux working perfectly on your QEMU machine
+3. Copy kernel over to your real 68000 hardware
+4. Notice that the kernel doesn't work
+5. Spend a day adding inline assembly all over the kernel to work out where the real hardware is locking up
+6. Find that the issue is probably memmove() being called with an unaligned src pointer:
+
+C level..
+
+```
+Breakpoint 1, memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152
+152                             *--sdest = *--ssrc;
+(gdb) bt
+#0  memmove (n=215, src=0x2059df <printk_shared_pbufs+215>, dest=0x2059ee <printk_shared_pbufs+230>) at ../arch/m68k/lib/memmove.c:152
+#1  memmove (dest=<optimized out>, src=<optimized out>, n=<optimized out>) at ../arch/m68k/lib/memmove.c:10
+#2  0x000265b6 in record_print_text (r=<optimized out>, syslog=<optimized out>, time=<optimized out>) at ../kernel/printk/printk.c:1472
+#3  0x00027be6 in printk_get_next_message (pmsg=<optimized out>, seq=<optimized out>, is_extended=<optimized out>, may_suppress=<optimized out>) at ../kernel/printk/printk.c:2952
+#4  0x00027e5a in console_emit_next_record (cookie=0, handover=0x1d9e37, con=0x1edf14 <early_con>) at ../kernel/printk/printk.c:3019
+#5  console_flush_all (do_cond_resched=false, next_seq=0x1d9e38, handover=0x1d9e37) at ../kernel/printk/printk.c:3118
+#6  0x00027fc8 in console_unlock () at ../kernel/printk/printk.c:3187
+#7  0x00028a04 in vprintk_emit (facility=0, level=<optimized out>, dev_info=0x0, fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2359
+#8  0x00028a26 in vprintk_default (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk.c:2374
+#9  0x00028c22 in vprintk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n", args=0x1d9e98) at ../kernel/printk/printk_safe.c:45
+#10 0x0019d016 in _printk (fmt=0x1bd051 "\0016printk: %s%sconsole [%s%d] enabled\n") at ../kernel/printk/printk.c:2384
+#11 0x0002857e in register_console (newcon=<optimized out>) at ../kernel/printk/printk.c:3693
+#12 0x001fbf1e in register_earlycon (match=<optimized out>, buf=0x0) at ../drivers/tty/serial/earlycon.c:161
+#13 setup_earlycon (buf=<optimized out>) at ../drivers/tty/serial/earlycon.c:212
+#14 0x001fbf72 in param_setup_earlycon (buf=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900") at ../drivers/tty/serial/earlycon.c:244
+#15 0x001f1102 in do_early_param (param=0x2009e0 <tmp_cmdline> "earlycon", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", unused=0x1b96c6 "early options", arg=0x0)
+    at ../init/main.c:744
+#16 0x00017eac in parse_one (handle_unknown=<optimized out>, arg=<optimized out>, max_level=<optimized out>, min_level=<optimized out>, num_params=<optimized out>, params=<optimized out>, 
+    doing=0x1b96c6 "early options", val=0x2009e9 <tmp_cmdline+9> "mc68ez328,0xfffff900", param=0x2009e0 <tmp_cmdline> "earlycon") at ../kernel/params.c:154
+#17 parse_args (doing=<optimized out>, args=0x2009fe <tmp_cmdline+30> "console=ttyDB0 root=/dev/mmcblk0p2 rootfstype=squashfs rootwait", params=<optimized out>, num=<optimized out>, 
+    min_level=<optimized out>, max_level=<optimized out>, arg=<optimized out>, unknown=<optimized out>) at ../kernel/params.c:189
+#18 0x001f13ea in parse_early_options (cmdline=0x2009e0 <tmp_cmdline> "earlycon") at ../init/main.c:754
+#19 0x001f1420 in parse_early_param () at ../init/main.c:769
+#20 0x001f1570 in start_kernel () at ../init/main.c:908
+#21 0x000004b8 in _clear_bss () at ../arch/m68k/dt/head.S:95
+#22 0x00000000 in ?? ()
+```
+
+Asm level:
+
+```
+152                             *--sdest = *--ssrc;
+   0x0019bed8 <+324>:   movel %a1,%d2
+   0x0019beda <+326>:   subql #2,%d2
+   0x0019bedc <+328>:   movel %a2,%d1
+   0x0019bede <+330>:   subql #2,%d1
+=> 0x0019bee0 <+332>:   movew %a1@(-2),%a2@(-2)
+```
+
+This is a word store so needs to be aligned but a1 isn't aligned so we should get an address error:
+
+```
+(gdb) print/x $a1
+$3 = 0x2059df
+(gdb) print/x $a2
+$4 = 0x2059ee
+```
+
+
+7. Check QEMU source code to work out why it doesn't crash the cpu at the same place.
+8. Notice it doesn't seem to check the alignment.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360
new file mode 100644
index 000000000..a67d1063a
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2360
@@ -0,0 +1,30 @@
+qemu-system-m68k: double mmu fault
+Description of problem:
+Shutting down Mac OS 7.5.3 after boot from CD image results in a double MMU fault.
+qemu: fatal: DOUBLE MMU FAULT
+
+D0 = 00000008   A0 = 22152a78   F0 = 7fff ffffffffffffffff  (         nan)\
+D1 = 40810000   A1 = 0000c190   F1 = 7fff ffffffffffffffff  (         nan)\
+D2 = 00010490   A2 = 000207a0   F2 = 7fff ffffffffffffffff  (         nan)\
+D3 = 0002befe   A3 = a88879d0   F3 = 7fff ffffffffffffffff  (         nan)\
+D4 = db6d0000   A4 = 00041a86   F4 = 7fff ffffffffffffffff  (         nan)\
+D5 = 00000000   A5 = 39ec4080   F5 = 7fff ffffffffffffffff  (         nan)\
+D6 = 00000001   A6 = 00053178   F6 = 7fff ffffffffffffffff  (         nan)\
+D7 = 07b6d258   A7 = 00000004   F7 = 7fff ffffffffffffffff  (         nan)\
+
+PC = 97f87008   SR = 2210 T:0 I:2 SI X---- \
+FPSR = 00000000 ---- \
+FPCR =     0000 X RN \
+A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000004 \
+VBR = 0x00000000 \
+SFC = 0 DFC 5 \
+SSW 00000505 TCR 0000c000 URP 00000000 SRP 07fffa00 \
+DTTR0/1: f900c060/807fc040 ITTR0/1: f900c060/807fc040 \
+MMUSR 00000000, fault at fffffffc \
+Steps to reproduce:
+1. Boot from CD image
+2. Choose Shut down from the Special menu
+Additional information:
+Reproducing requires a quadra 800 rom file.\
+A CD image (f.e. SYSTEM_7-5-3-RETAIL.ISO) can be obtained here: https://macintoshgarden.org/apps/macintosh-os-755 \
+Also see here: https://gitlab.com/qemu-project/qemu/-/issues/2249
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468
new file mode 100644
index 000000000..b463f1c58
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2468
@@ -0,0 +1,33 @@
+m68k: movec to/from CAAR not emulated?
+Description of problem:
+
+Steps to reproduce:
+1. Start adding a machine for the Motorola MVME147 VME module
+2. Step through the standard ROM for this board (147BUG)
+3. Step until `ff823bf0 4e 7b 18 02     movec      D1,CAAR`
+4. Watch QEMU show a fatal error for an unimplemented control register:
+
+```
+QEMU 9.0.50 monitor - type 'help' for more information
+(qemu) qemu: fatal: Unimplemented control register write 0x802 = 0xffffffff
+
+D0 = ffffffff   A0 = fffe0000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = ffffffff   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = ffff271f   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = ffffffff   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = ffffffff   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = ffffffff   A5 = 00000400   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = ffffffff   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = ffffffff   A7 = 000037dc   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff823bf0   SR = 2714 T:0 I:7 SI X-Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = ffffffff ->A7(ISP) = 000037dc
+VBR = 0xffffffff
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+Additional information:
+
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479
new file mode 100644
index 000000000..47e46db84
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2479
@@ -0,0 +1,30 @@
+Unable to remotely debug with gdbserver on debian while using qemu-system-m68k emulator
+Description of problem:
+When I use gdb-multiarch to try to connect to the gdbserver running on the guest machine the error message below is displayed by the gdbserver:
+
+```
+/build/gdb-Lhte76/gdb-13.2/gdbserver/tdesc.cc:195: A problem internal to GDBserver has been detected.
+tdesc_get_features_xml: Assertion `tdesc->xmltarget != NULL || (!tdesc->features.empty () && tdesc->arch != NULL)' failed.
+```
+
+and the program execution is terminated abruptly.
+Steps to reproduce:
+1. Download the Debian Motorola 680x0 Port and install it using QEmu.
+2. Update to unstable version (optional).
+3. Download and install gdbserver and also a compiler for the C language.
+4. Write a hello world and compile.
+5. Run gdbserver targeting the program from the previous step.
+6. Try connecting using gdb-multiarch.
+Additional information:
+The error persists when I download the QEmu source code and compile it.
+
+If this procedure is done with an older version of gdbserver (such as 7.12) then I can connect normally. However, if a breakpoint is placed anywhere in the program and if it is reached at any point during execution and if after it is reached the 'continue' command is entered, then the error message below is displayed by the gdbserver:
+
+```
+linux-low.c:2627: A problem internal to GDBserver has been detected.
+int maybe_hw_step(thread_info*): Assertion `has_reinsert_breakpoints (thread)' failed.
+```
+
+and the program execution is terminated abruptly.
+
+I think it's working on real hardware.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483
new file mode 100644
index 000000000..df22f6afa
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2483
@@ -0,0 +1,20 @@
+m68k: jsr (sp) doesn't work as expected
+Description of problem:
+Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first.
+
+```
+        ff8241e6 22 4f           movea.l    SP,A1
+        ff8241e8 70 68           moveq      #0x68,D0
+                             LAB_ff8241ea                                    XREF[1]:     ff8241ee(j)  
+        ff8241ea 12 d8           move.b     (A0)+,(A1)+
+        ff8241ec 53 80           subq.l     #0x1,D0
+        ff8241ee 66 fa           bne.b      LAB_ff8241ea
+        ff8241f0 4e 97           jsr        (SP)
+```
+
+`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think?
+What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails.
+
+Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing.
+
+![image](/uploads/d5fd6f455e5a433735d8fae2be3d53ee/image.png){width=289 height=759}
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488
new file mode 100644
index 000000000..1234227e5
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2488
@@ -0,0 +1,65 @@
+m68k: 68030 (?): fmove.p doesn't work (6888[1|2] emulation isn't implemented??)
+Description of problem:
+The following code should be executing a move to the fpu and then a move from it and then branching.
+
+```
+        ff813590 f2 10 4f 00     fmove.p    (A0),FP6
+        ff813594 f2 11 6f 7f     fmove.p    FP6,(A1) {#0x7f}
+        ff813598 61 00 fe 52     bsr.w      SUB_ff8133ec
+```
+
+However, hitting the instruction at `0xff813590` causes the `PC` to go off into the weeds and then the emulation gets stuck and never proceeds.
+
+Before executing the instruction the CPU state looks like this
+
+```
+(qemu) info registers
+
+CPU#0
+D0 = ffffffff   A0 = ff813584   F0 = c004 cc00000000000000  (         -51)
+D1 = 0000ffff   A1 = 0000335e   F1 = c00d a866000000000000  (      -21555)
+D2 = 00000002   A2 = ff8138a2   F2 = 401b 91a2b3c000000000  (  3.0542e+08)
+D3 = 00000003   A3 = ff824008   F3 = 3fb4 ab3c4d0000000000  ( 3.54107e-23)
+D4 = 00000004   A4 = ff81dbb6   F4 = 3d12 919a22ab33bc4000  (3.84141e-226)
+D5 = 00000000   A5 = 00000400   F5 = 1020 8060708090a0b0c0  (           0)
+D6 = 0000000c   A6 = 00003790   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 0000316e   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff813590   SR = 2708 T:0 I:7 SI -N---
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = 80000000 ->A7(ISP) = 00003796
+VBR = 0x0000338e
+SFC = 3 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+
+After single stepping:
+
+```
+(qemu) info registers
+
+CPU#0
+D0 = ffffffff   A0 = ff813584   F0 = c004 cc00000000000000  (         -51)
+D1 = 0000ffff   A1 = 0000335e   F1 = c00d a866000000000000  (      -21555)
+D2 = 00000002   A2 = ff8138a2   F2 = 401b 91a2b3c000000000  (  3.0542e+08)
+D3 = 00000003   A3 = ff824008   F3 = 3fb4 ab3c4d0000000000  ( 3.54107e-23)
+D4 = 00000004   A4 = ff81dbb6   F4 = 3d12 919a22ab33bc4000  (3.84141e-226)
+D5 = 00000000   A5 = 00000400   F5 = 1020 8060708090a0b0c0  (           0)
+D6 = 0000000c   A6 = 00003790   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00003166   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff8138a2   SR = 2708 T:0 I:7 SI -N---
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = 80000000 ->A7(ISP) = 0000316e
+VBR = 0x0000338e
+SFC = 3 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+
+With this code the `VBR` doesn't point at an actual vector table from what I can tell and it is pointing at some memory that contains `0xff8138a2` so I guess it hits the instruction, the FPU isn't implemented so it tries to do an `F-line exception` instead but the vector table doesn't actually contain a handler and it's trying to execute garbage that causes the lock up.
+
+Basically, I guess I need to implement the 6888[1|2] for this code to work.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497
new file mode 100644
index 000000000..edf8d6abb
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2497
@@ -0,0 +1,3 @@
+m68k: fpu: FPIAR register is not implemented
+Description of problem:
+QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498
new file mode 100644
index 000000000..c62e8062a
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2498
@@ -0,0 +1,51 @@
+m68k: fpu: fmovem with multiple control registers has incorrect in memory order
+Description of problem:
+It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers.
+
+According to the manual:
+
+```
+The
+registers are always moved in the same order, regardless of the addressing mode
+used; the floating-point control register is moved first, followed by the floating-point
+status register, and the floating-point instruction address register is moved last.
+```
+
+Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary.
+
+Maybe something like this is needed:
+
+``` diff
+commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt)
+Author: Daniel Palmer <daniel@thingy.jp>
+Date:   Tue Aug 13 09:52:54 2024 +0900
+
+    fix fmovem ordering
+
+diff --git a/target/m68k/translate.c b/target/m68k/translate.c
+index 92dc9d8563..64ff2df06e 100644
+--- a/target/m68k/translate.c
++++ b/target/m68k/translate.c
+@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+      */
+ 
+     if (is_write && mode == 4) {
+-        for (i = 2; i >= 0; i--, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 gen_qemu_store_fcr(s, addr, 1 << i);
+                 if (mask != 1) {
+                     tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG));
+@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s,
+        }
+        tcg_gen_mov_i32(AREG(insn, 0), addr);
+     } else {
+-        for (i = 0; i < 3; i++, mask >>= 1) {
+-            if (mask & 1) {
++        for (i = 2; i >= 0; i--, mask <<= 1) {
++            if (mask & 0b100) {
+                 if (is_write) {
+                     gen_qemu_store_fcr(s, addr, 1 << i);
+                 } else {
+```
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499
new file mode 100644
index 000000000..19ff522d0
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2499
@@ -0,0 +1,30 @@
+m68k: fpu: fsave/frestore should be enabled for 68020/68030
+Description of problem:
+valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception.
+
+I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences.
+
+``` diff
+diff --git a/target/m68k/translate.c b/target/m68k/translate.c
+index d5d2322329..92dc9d8563 100644
+--- a/target/m68k/translate.c
++++ b/target/m68k/translate.c
+@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore)
+         gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE);
+         return;
+     }
+-    if (m68k_feature(s->env, M68K_FEATURE_M68040)) {
++    if (m68k_feature(s->env, M68K_FEATURE_FPU)) {
+         SRC_EA(env, addr, OS_LONG, 0, NULL);
+         /* FIXME: check the state frame */
+     } else {
+@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave)
+         return;
+     }
+ 
+-    if (m68k_feature(s->env, M68K_FEATURE_M68040)) {
++    if (m68k_feature(s->env, M68K_FEATURE_FPU)) {
+         /* always write IDLE */
+         TCGv idle = tcg_constant_i32(0x41000000);
+         DEST_EA(env, insn, OS_LONG, idle, NULL);
+```
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500
new file mode 100644
index 000000000..4ac7610a4
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2500
@@ -0,0 +1,4 @@
+m68k: mmu: 68030 mmu instructions are missing
+Description of problem:
+The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??).
+QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507
new file mode 100644
index 000000000..948a843ed
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2507
@@ -0,0 +1,13 @@
+m68k: fpu: frestore with NULL state should reset FPU state
+Description of problem:
+According to the PRM:
+
+```
+Floating-Point Status Register: Cleared if the state size is NULL; otherwise, not affected. 
+```
+
+But this does not currently happen.
+Steps to reproduce:
+1. set a value in fpsr
+2. do frestore with state size zero
+3. read back fpsr and notice it isn't zero.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675
new file mode 100644
index 000000000..d47843ac5
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2675
@@ -0,0 +1,11 @@
+q800 machine is broken when compiling with --enable-cfi
+Description of problem:
+When compiling QEMU that is configured like this:
+```
+ .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang
+```
+the q800 machine crashes with an illegal exception on the host very early, somewhere during q800_machine_init()
+Steps to reproduce:
+1. .../configure --target-list=m68k-softmmu --enable-cfi --cc=clang
+2. make qemu-system-m68k
+3. ./qemu-system-m68k -M q800
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794
new file mode 100644
index 000000000..b0d82664b
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2794
@@ -0,0 +1,49 @@
+qemu-system-m68k virt machine doesn't boot Linux kernels using 68020, 68030 and 68060 CPUs
+Description of problem:
+QEMU doesn't seem to be able to start Linux kernels using a CPU other than a 68040 (which does work fine)
+
+To rule out host issues, the issue is reproductible on Debian Unstable amd64 (with version QEMU emulator version 9.2.0)(Debian 1:9.2.0+ds-5))
+
+To rule out cross-compilation issues, the kernel has been rebuild inside a virt machine (using a 68040 CPU), running Debian Unstable 
+
+Each CPU model below gets stuck early before kernel boot during the ABCGHIJK thing. The Kernel doesn't seem to boot and QEMU process eat 100% of a CPU physical core
+
+**68020**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABCGH
+```
+
+**68030**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+
+**68060**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+Steps to reproduce:
+1. build a kernel with 68020/030/060 support (using virt_defconfig as base)
+2. start QEMU with the command line above
+Additional information:
+68020 is understandable as it may need some sort of 68851 emulation.
+
+Relevant Kernel config Processor configuration:
+```
+#
+# Processor Type
+#
+CONFIG_M68KCLASSIC=y
+# CONFIG_COLDFIRE is not set
+CONFIG_M68020=y
+CONFIG_M68030=y
+CONFIG_M68040=y
+CONFIG_M68060=y
+```
+
+This may be related to the following issues (but I don't have the skillset to confirm that)
+- https://gitlab.com/qemu-project/qemu/-/issues/2091
+- https://gitlab.com/qemu-project/qemu/-/issues/2500
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807
new file mode 100644
index 000000000..b68aba30d
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2807
@@ -0,0 +1,31 @@
+DOUBLE MMU FAULT when running -M virt in qemu-system-m68k
+Description of problem:
+When running qemu-system-m68k with the -M virt machine type, a DOUBLE MMU FAULT occurs immediately upon startup, even without any BIOS, disk image, or additional configuration.
+Steps to reproduce:
+1. qemu-system-m68k -M virt -m 4M -serial stdio
+
+QEMU crashes immediately with the following output:
+```
+qemu: fatal: DOUBLE MMU FAULT
+D0 = 00000000   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00000000   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00400000   SR = 2704 T:0 I:7 SI --Z--
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000105 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at fffffffc
+```
+Additional information:
+The issue seems to be related to incorrect memory initialization, causing a fault at address fffffffc.
+The PC = 00400000 suggests that QEMU is jumping to an invalid address early in the boot process.
+The fact that the fault is consistent across different configurations (q800, next-cube, etc) points to a possible regression or incomplete memory initialization in the virt machine.
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812
new file mode 100644
index 000000000..d0b1a4251
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/2812
@@ -0,0 +1 @@
+Crash initializing audio device
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/442 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/442
new file mode 100644
index 000000000..c54fb91d3
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/442
@@ -0,0 +1 @@
+Firebird crashes on qemu-m68k-user with pthread_mutex_init error
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/710 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/710
new file mode 100644
index 000000000..636302c0a
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/710
@@ -0,0 +1 @@
+maybe-uninitialized warning building target/m68k/ with -O3
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/756 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/756
new file mode 100644
index 000000000..ac383d4bb
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/756
@@ -0,0 +1 @@
+qemu-system-m68k -M q800 -bios /dev/null segfaults
diff --git a/gitlab/issues_text/target_m68k/host_missing/accel_missing/957 b/gitlab/issues_text/target_m68k/host_missing/accel_missing/957
new file mode 100644
index 000000000..3f0733cf4
--- /dev/null
+++ b/gitlab/issues_text/target_m68k/host_missing/accel_missing/957
@@ -0,0 +1,71 @@
+qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code."
+Description of problem:
+The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is
+```
+The futex facility returned an unexpected error code.
+```
+
+Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``.
+
+Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument".
+
+
+```
+116876 get_thread_area(0x00000001) = 989882672
+116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672
+ = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744
+futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000)
+ = 1065219744
+0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744
+116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument)
+ = 0
+ = 116876 get_thread_area(0x3f7d4c34)1 = 
+116876 get_thread_area(0x00000000) = 1065219744
+926968112
+116876 get_thread_area(0x00000016) = 926968112
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000001)116876  = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112
+116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE
+,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112
+1065219744
+116876 get_thread_area(0x00000001)116876  = 1065219744
+1073732112) = 116876 -1 errno=22 (Invalid argument)
+futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112)
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0
+116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+ = 0
+116876 get_thread_area(0x40053a8c) = 885025072
+116876 get_thread_area(0x00000001) = 885025072
+116876 get_thread_area(0x00b4b456) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 Unknown syscall 403
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00003baa) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112
+116876 get_thread_area(0x00000018) = 926968112
+116876 get_thread_area(0x3ed5b9c8) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x0000000f) = 926968112116876  = 0
+
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112
+The futex facility returned an unexpected error code.
+116876 get_thread_area(0x3f7d4c30) = 885025072
+```
+
+Advice on how to do further debuggging is appreciated.