Re: 'continue' command problem

Re: 'continue' command problem

[Vladimir Prus]

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

Re: 'continue' command problem

[Nick Roberts]

 > 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?

I've abandoned the branch but have a much smaller patch that does something
similar.  It should emit all asynchronous records but I'm not sure what
what happens inside a user-defined command.

It's not really a quick fix for a specific problem but a different approach
to a more general one.  The patch is at:

http://sourceware.org/ml/gdb-patches/2006-11/msg00225.html

and there has been more recent discussion about it on gdb-patches this month
(Re: async patch (no. 4)).

I have a working copy so I can send you a current patch privately if you want
to try it out.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: '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

Re: 'continue' command problem

[Nick Roberts]

Jim Ingham writes:
 > At Apple, we also added a "breakpoint-commands" output field to the  
 > "*stopped - breakpoint-hit" message. 

I can see an MI command -break-commands but no output field,
"breakpoint-commands".  Which file is it in?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 'continue' command problem

[Jim Ingham]

Ah, sorry, I just called the field "commands".  It's done in  
breakpoint.c, in "print_it_typical" (in the Apple sources).

The way I implemented it, I added a *started message to tell the UI  
that we had restarted because of a breakpoint command, as well as a  
^continuing.  I forget exactly why I chose to do it this way, it's  
maybe a little overdetermined.  (Note, we also added a -breakpoint- 
commands" command to set the breakpoint commands...)

Anyway, this looks like:

gdbrulez:/tmp > gdb a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-688) (Sat Jun 16 20:20:22  
UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for  
shared libraries ... done

(gdb) list main
1	int
2	main ()
3	{
4	  int foo = 0;
5	
6	  while (foo < 100)
7	    {
8	      foo++;
9	    }
10	
(gdb) break 8
Breakpoint 1 at 0x1fa1: file main.c, line 8.
(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
 >print foo
 >continue
 >end
(gdb) set interpreter mi1
-exec-run
~"[Switching to process 19582 local thread 0x1103]\n"
=shlibs-updated
^running
(gdb)
~"$1 = 0"
~"\n"
~"Continuing.\n"
^continuing
*started,reason="breakpoint-command"
*stopped 
,time 
= 
{wallclock 
= 
"0.00153 
",user 
= 
"0.00046 
",system 
= 
"0.00098 
",start 
="1182881550.648028",end="1182881550.649559"},reason="breakpoint- 
hit",commands="yes",times="2",bkptno="1",thread-id="1"
~"$2 = 1"
~"\n"
~"Continuing.\n"
^continuing
*started,reason="breakpoint-command"
*stopped 
,time 
= 
{wallclock 
= 
"0.00101 
",user 
= 
"0.00034 
",system 
= 
"0.00071 
",start 
="1182881550.649577",end="1182881550.650586"},reason="breakpoint- 
hit",commands="yes",times="3",bkptno="1",thread-id="1"
~"$3 = 2"
~"\n"
~"Continuing.\n"
^continuing

Jim

On Jun 25, 2007, at 9:39 PM, Nick Roberts wrote:

> Jim Ingham writes:
>> At Apple, we also added a "breakpoint-commands" output field to the
>> "*stopped - breakpoint-hit" message.
>
> I can see an MI command -break-commands but no output field,
> "breakpoint-commands".  Which file is it in?
>
>
> -- 
> Nick                                           http://www.inet.net.nz/~nickrob

Re: 'continue' command problem

[Nick Roberts]

 > Ah, sorry, I just called the field "commands".  It's done in  
 > breakpoint.c, in "print_it_typical" (in the Apple sources).

OK, thanks for the info.

 > The way I implemented it, I added a *started message to tell the UI  
 > that we had restarted because of a breakpoint command, as well as a  
 > ^continuing.  I forget exactly why I chose to do it this way, it's  
 > maybe a little overdetermined.  (Note, we also added a -breakpoint- 
 > commands" command to set the breakpoint commands...)
 > 
 > Anyway, this looks like:

 >...
 > (gdb) break 8
 > Breakpoint 1 at 0x1fa1: file main.c, line 8.
 > (gdb) commands 1
 > Type commands for when breakpoint 1 is hit, one per line.
 > End with a line saying just "end".
 >  >print foo
 >  >continue
 >  >end
 > (gdb) set interpreter mi1
 > -exec-run
 > ~"[Switching to process 19582 local thread 0x1103]\n"
 > =shlibs-updated
 > ^running
 > (gdb)
 > ~"$1 = 0"
 > ~"\n"
 > ~"Continuing.\n"
 > ^continuing
 > *started,reason="breakpoint-command"

"breakpoint-command" comes before the first "breakpoint-hit" ?

 > *stopped 
 > ,time 
 > = 
 > {wallclock 
 > = 
 > "0.00153 
 > ",user 
 > = 
 > "0.00046 
 > ",system 
 > = 
 > "0.00098 
 > ",start 
 > ="1182881550.648028",end="1182881550.649559"},reason="breakpoint- 
 > hit",commands="yes",times="2",bkptno="1",thread-id="1"
 > ~"$2 = 1"
 > ~"\n"
 > ~"Continuing.\n"
 > ^continuing
 >...

If Apple GDB can handle command lists, I guess user defined functions work
too.  Isn't asynchronous operation a problem here because the second
command can start executing before the first command has finished?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 'continue' command problem

[Vladimir Prus]

Jim Ingham wrote:

> 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.

Actually, the original bug report is not related to breakpoint commands.
Now, gdb does not emit "^running" on any CLI commands at all -- like
"continue", or "until". And when such commands are used inside gdb macro,
we're completely out of luck.

I'd imagine that "continue" used in breakpoint commands should also
emit "^running", but I'm not sure about this part.

- Volodya