diff options
Diffstat (limited to 'results/classifier/105/socket/1030666')
| -rw-r--r-- | results/classifier/105/socket/1030666 | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/results/classifier/105/socket/1030666 b/results/classifier/105/socket/1030666 new file mode 100644 index 00000000..0cba8947 --- /dev/null +++ b/results/classifier/105/socket/1030666 @@ -0,0 +1,114 @@ +socket: 0.945 +semantic: 0.945 +network: 0.942 +other: 0.939 +instruction: 0.930 +assembly: 0.927 +boot: 0.914 +device: 0.904 +graphic: 0.901 +mistranslation: 0.873 +vnc: 0.853 +KVM: 0.824 + +gdb can't proceed after a breakpoint + +Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/ +Host: Windows 7 Ultimate 64-bit +Guest: i386 system running MS-DOS 6.22 +Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 +Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + +Short description: +I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + +Steps to reproduce: +DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. +Data.vfd is a floppy image containing a single program (hello.com). +The aim is to debug the execution of hello.com with gdb. +Launch Qemu. +Launch gdb, an attach to qemu: + "target remote localhost:1234" +I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" +In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. +Examining the program gives expected results (such as "info reg" or "disassemble"). +At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. +The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + +Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +Hi, + +Thank you for your email, I remember this issue. Unfortunately I don’t have the time to try this right now, but I may be able to get to it in the next couple of weeks. + +Regards, +Legorol + +From: Thomas Huth +Sent: 07 April 2017 14:59 +To: <email address hidden> +Subject: [Bug 1030666] Re: gdb can't proceed after a breakpoint + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +** Changed in: qemu + Status: New => Incomplete + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1030666 + +Title: + gdb can't proceed after a breakpoint + +Status in QEMU: + Incomplete + +Bug description: + Using qemu-1.1.0-windows.zip package from http://lassauge.free.fr/qemu/ + Host: Windows 7 Ultimate 64-bit + Guest: i386 system running MS-DOS 6.22 + Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 + Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + + Short description: + I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + + Steps to reproduce: + DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. + Data.vfd is a floppy image containing a single program (hello.com). + The aim is to debug the execution of hello.com with gdb. + Launch Qemu. + Launch gdb, an attach to qemu: + "target remote localhost:1234" + I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" + In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. + Examining the program gives expected results (such as "info reg" or "disassemble"). + At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. + The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + + Note that single-stepping and continue works as expected if it is done + after interrupting execution with Ctrl-C. + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1030666/+subscriptions + + + +[Expired for QEMU because there has been no activity for 60 days.] + |