All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1030666] [NEW] gdb can't proceed after a breakpoint
@ 2012-07-30  1:41 Legorol
  2012-07-30  1:55 ` [Qemu-devel] [Bug 1030666] " Legorol
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Legorol @ 2012-07-30  1:41 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New


** Tags: breakpoint gdb

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1030666

Title:
  gdb can't proceed after a breakpoint

Status in QEMU:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1030666/+subscriptions

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1030666] Re: gdb can't proceed after a breakpoint
  2012-07-30  1:41 [Qemu-devel] [Bug 1030666] [NEW] gdb can't proceed after a breakpoint Legorol
@ 2012-07-30  1:55 ` Legorol
  2017-04-07 13:47 ` Thomas Huth
  2017-06-14  4:17 ` Launchpad Bug Tracker
  2 siblings, 0 replies; 5+ messages in thread
From: Legorol @ 2012-07-30  1:55 UTC (permalink / raw)
  To: qemu-devel

** Description changed:

- Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/
+ 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
+   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
+   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"
+   "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"
+   "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.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1030666

Title:
  gdb can't proceed after a breakpoint

Status in QEMU:
  New

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1030666] Re: gdb can't proceed after a breakpoint
  2012-07-30  1:41 [Qemu-devel] [Bug 1030666] [NEW] gdb can't proceed after a breakpoint Legorol
  2012-07-30  1:55 ` [Qemu-devel] [Bug 1030666] " Legorol
@ 2017-04-07 13:47 ` Thomas Huth
  2017-04-14 12:02   ` Legorol
  2017-06-14  4:17 ` Launchpad Bug Tracker
  2 siblings, 1 reply; 5+ messages in thread
From: Thomas Huth @ 2017-04-07 13:47 UTC (permalink / raw)
  To: qemu-devel

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 a member of qemu-
devel-ml, which is subscribed to QEMU.
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [Bug 1030666] Re: gdb can't proceed after a breakpoint
  2017-04-07 13:47 ` Thomas Huth
@ 2017-04-14 12:02   ` Legorol
  0 siblings, 0 replies; 5+ messages in thread
From: Legorol @ 2017-04-14 12:02 UTC (permalink / raw)
  To: qemu-devel

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: legorol.san@gmail.com
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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Qemu-devel] [Bug 1030666] Re: gdb can't proceed after a breakpoint
  2012-07-30  1:41 [Qemu-devel] [Bug 1030666] [NEW] gdb can't proceed after a breakpoint Legorol
  2012-07-30  1:55 ` [Qemu-devel] [Bug 1030666] " Legorol
  2017-04-07 13:47 ` Thomas Huth
@ 2017-06-14  4:17 ` Launchpad Bug Tracker
  2 siblings, 0 replies; 5+ messages in thread
From: Launchpad Bug Tracker @ 2017-06-14  4:17 UTC (permalink / raw)
  To: qemu-devel

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1030666

Title:
  gdb can't proceed after a breakpoint

Status in QEMU:
  Expired

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-06-14  4:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-30  1:41 [Qemu-devel] [Bug 1030666] [NEW] gdb can't proceed after a breakpoint Legorol
2012-07-30  1:55 ` [Qemu-devel] [Bug 1030666] " Legorol
2017-04-07 13:47 ` Thomas Huth
2017-04-14 12:02   ` Legorol
2017-06-14  4:17 ` Launchpad Bug Tracker

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.