diff options
Diffstat (limited to 'results/classifier/108/other/640213')
| -rw-r--r-- | results/classifier/108/other/640213 | 43 |
1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/108/other/640213 b/results/classifier/108/other/640213 new file mode 100644 index 000000000..fe63d95cd --- /dev/null +++ b/results/classifier/108/other/640213 @@ -0,0 +1,43 @@ +graphic: 0.918 +debug: 0.867 +semantic: 0.837 +performance: 0.792 +boot: 0.743 +files: 0.725 +device: 0.719 +other: 0.680 +permissions: 0.639 +network: 0.637 +PID: 0.622 +socket: 0.614 +vnc: 0.533 +KVM: 0.443 + +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.] + |