'continue' command problem

[Jim Ingham]

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.

Jim

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]
>
>> Hello.
>>
>> 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.
>
> Nick,
> 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