Re: [mi] watchpoint-scope exec async command

[Bob Rossi <bob at brasko dot net>]

On Sat, Mar 26, 2005 at 03:24:10PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 25 Mar 2005 11:12:39 -0500
> > From: Bob Rossi <bob@brasko.net>
> > 
> > (gdb)
> > -break-watch param
> > ^done,wpt={number="2",exp="param"}
> > (gdb)
> > -exec-continue
> > ^running
> > (gdb)
> > ~"Hardware watchpoint 2 deleted because the program has left the block \n"
> > ~"in which its expression is valid.\n"
> > *stopped,reason="exited",exit-code="02"
> > (gdb)
> > 
> > Is it just a bug that there is no 'watchpoint-scope' returned?
> 
> I think it's a bug, yes: there's one instance in breakpoint.c
> (specifically, in the function insert_bp_location) that uses
> printf_filtered instead of the ui_* functions to produce the warning
> about a watchpoint that went out of scope.  I think it should use the
> same code that is used by watchpoint_check to produce a similar
> warning.

Sorry, long email, please scan quickly.

Unfortunately, this is going to much harder than I originally thought. In
fact, it looks like the whole thing is broken.

I think part of the problem is the fact that the way the MI output is
generated is hackish. I think it's kind of bad that the MI output is
basically concatenated strings from the rest of GDB.  For instance, 
I think it would be much better if there were data structures available, 
and the breakpoint code set up structures with the information that the 
MI needed. Then later on, the MI could traverse the structure and print 
what it wanted to. In that way, all of the information needed could be 
used to print a message at once.

It seems as if the watchpoint-scope has 2 problems that I can find. The
first is that the manual says,
   Setting a watchpoint on a variable local to a function. GDB will stop
   the program execution twice: first for the variable changing value,
   then for the watchpoint going out of scope.

   ...
   -exec-continue
   ^running
   ^done,reason="watchpoint-scope",wpnum="5",
   frame={func="callee3",args=[{name="strarg",
   value="0x11940 \"A string argument.\""}],
   file="../../../devo/gdb/testsuite/gdb.mi/basics.c",line="18"}
   (gdb)

In the above example, things work fine. However, if you happen to use
-exec-next or -exec-finish, something that by itself produces an
exec-async-output command, then instead of having 2 async output
commands, you get 1, with the data combined. Two example are below, 1
with -exec-continue, and one with -exec-next

   (gdb) 
   -exec-continue
   ^running
   (gdb) 
   ~"Hardware watchpoint 2 deleted because the program has left the block \n"
   ~"in which its expression is valid.\n"
   *stopped,reason="watchpoint-scope",reason="exited",exit-code="02"
   (gdb) 

   (gdb) 
   -exec-next
   ^running
   (gdb) 
   ~"Single stepping until exit from function __libc_start_main, \n"
   ~"which has no line number information.\n"
   ~"Hardware watchpoint 2 deleted because the program has left the block \n"
   ~"in which its expression is valid.\n"
   *stopped,reason="watchpoint-scope",reason="exited-normally"
   (gdb) 

Both of the examples above give 2 reasons for the async command.
So, the MI syntax is correct, but the semantics are completely wrong. I
think it's currently impossible to return 2 async records in 1 MI output
command. This is because in mi-main.c the *stopped is hard coded, as if
there could only be 1 async reason per command. 

There will probably have to be some fundamental changes in order to get
this to work. I think the rest of GDB needs to be able to tell MI
through the uiout that a new async record is ready to be sent, instead
of having the MI hard code it.

Thanks,
Bob Rossi