This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 'continue' command problem

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 maintainer):

When the user defined gdb macro contains "continue" command inside, this
causes the debugger interface to loose its head (BP hit, ball/ circle/point
presentation and BP tab are in disorder).

This is more or less expected. In this case GDB fails to inform us that
the target started running, so we think it's stopped, and many bad things
can happen.

I think your "async branch" is supposed to emit "^running" in all possible cases.
Is that the case, and if so, do you think that improvement can be ported to
gdb mainline quickly?

- Volodya

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]