This is the mail archive of the
mailing list for the GDB project.
Re: 'continue' command problem
- From: Jim Ingham <jingham at apple dot com>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: kdevelop at kdevelop dot org, Nick Roberts <nickrob at snap dot net dot nz>, gdb at sources dot redhat dot com
- Date: Mon, 25 Jun 2007 11:04:30 -0700
- Subject: Re: 'continue' command problem
- References: <email@example.com> <firstname.lastname@example.org>
At Apple, we also added a "breakpoint-commands" output field to the
"*stopped - breakpoint-hit" message. Then we either tell it that the
breakpoint commands are done running, or that they have restarted the
target. That way the UI can know to suspend putting up some UI
(getting the current stack, etc) till it knows the target has stopped
for sure... After all, one very common use of breakpoint commands is
on the fly logging, in which case you do want to display whatever the
breakpoint command prints in your gdb console log window, but you
don't want to do anything else.
On Jun 25, 2007, at 12:01 AM, Vladimir Prus wrote:
On Monday 04 June 2007 15:21, Leon Pollak wrote:
[cross-posting to gdb-devel]
This is the message to Vladimir Prus (as the debugger interface
When the user defined gdb macro contains "continue" command inside,
causes the debugger interface to loose its head (BP hit, ball/
presentation and BP tab are in disorder).
This is more or less expected. In this case GDB fails to inform us
the target started running, so we think it's stopped, and many bad
I think your "async branch" is supposed to emit "^running" in all
Is that the case, and if so, do you think that improvement can be
gdb mainline quickly?