1 files changed, 58 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/640213 b/results/classifier/118/graphic/640213
new file mode 100644
index 000000000..bbb872321
--- /dev/null
+++ b/results/classifier/118/graphic/640213
@@ -0,0 +1,58 @@
+graphic: 0.918
+x86: 0.915
+kernel: 0.908
+debug: 0.867
+semantic: 0.837
+architecture: 0.833
+performance: 0.792
+user-level: 0.791
+boot: 0.743
+files: 0.725
+device: 0.719
+mistranslation: 0.717
+permissions: 0.639
+network: 0.637
+ppc: 0.637
+PID: 0.622
+socket: 0.614
+vnc: 0.533
+VMM: 0.526
+risc-v: 0.523
+i386: 0.523
+register: 0.507
+hypervisor: 0.501
+assembly: 0.490
+peripherals: 0.484
+arm: 0.444
+KVM: 0.443
+TCG: 0.335
+virtual: 0.308
+
+QEMU does not communicate properly with GDB with a 64 bit guest
+
+I have been trying to figure out why I cannot debug a 64 bit kernel of my own invention.
+
+I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel and GRUB2.
+
+When I try to set breakpoints and "continue" in GDB (7.2) using the very latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or 0.12.5 or 13.0.rc0 or 13.0.rc1, I get failures of the same nature:
+
+0x0000000000000000 in ?? ()
+(gdb) break main
+Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18.
+(gdb) c
+
+Program received signal SIGTRAP, Trace/breakpoint trap.
+0x0000000000000000 in ?? ()
+(gdb)
+
+Note that in this case, main lies in 64 bit mode. However, trying to break on _start yields virtually the same effect and _start is 32 bit code.
+
+By doing a git bisect, I managed to narrow the commit that introduced this bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases.
+I might be doing something incorrectly on my end but this seemed to fix the problem.
+
+Perhaps the pertinent thing to do would be to revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing but break things unless, of course, this would only break something that I am not aware of further.
+
+Can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+