Re: MI query questions

[Jim Ingham <jingham@apple.com>]

What we did for this is along the lines Daniel suggested.  When we  
find multiple matches to a breakpoint, we return "matches", and then  
a list of matches, something like:

^done,matches={b={index="0",canonical="-[NSException raise]",binary="/ 
System/Library/Frameworks/Foundation.framework/Versions/C/ 
Foundation",line="0",addr="0x9294d008"},b= 
{index="1",canonical="raise",binary="/usr/lib/ 
libSystem.B.dylib",line="0",addr="0x9012f940"}}

Then you have to provide some way for the UI to turn around and set  
the breakpoints it wants to set.  You aren't really guaranteed that  
the UI will know how to cons up a breakpoint expression that will  
return the breakpoint you want.  We tried using the canonical form,  
and with that and the shared library you could do it mostly, except  
if we start doing things like template breakpoints.  So we added a -l  
option to -break-insert that takes a list of the indices and sets the  
breakpoints for that list.

It might have been cleaner to tie the list to the original -break- 
insert command, like having -break-insert pass back a cookie along  
with the matches, and then do:

-break-confirm <cookie> <list>

But I wanted to keep it stateless to make the implementation in gdb  
simpler.  So the UI just sends the -break-insert twice, the second  
time with the list.  You can also send "-1" for the list, and we will  
automatically accept all the breakpoints.

Jim


On May 29, 2006, at 7:46 AM, Daniel Jacobowitz wrote:

> On Mon, May 29, 2006 at 08:23:37AM -0400, Bob Rossi wrote:
>> The first small issue is that the '[1] all\n' choice is on the same
>> line as the [0] choice.
>
> That's because the ~"" blocks come from individual calls to printf.
>
>> The second issue is how GDB outputs a final ">" line. This isn't a  
>> valid
>> GDB/MI Output record/command. At least, I don't think it is. If I  
>> select
>> an option, then I get this
>
>> Which looks pretty good to me. So the problem is, the line ">"
>> apparently means to get input from the user. This isn't specified  
>> in the
>> MI OUTPUT record. Should we change the OUTPUT record to represent
>> interactive commands?
>
> I don't really think we should shoehorn these queries into MI.  It
> would make more sense to me to have it do something MI-like.  For
> example, not set any breakpoint, but return a more exact list of  
> places
> the breakpoint could be placed.  If you want the query behavior, you
> could of course use interpreter-exec :-)
>
> I dunno what that new response would look like, and I'm not especially
> interested in working it out; just sharing my opinion.  The > bit is
> very un-MI, and e.g. it prevents pipelining MI commands.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery