Re: MI query questions

[Jim Ingham <jingham@apple.com>]

Actually, to avoid confusion, this really looks like:

(gdb) set interpreter mi1
-interpreter-exec console-quoted "break raise"
~"[0] cancel\n[1] all\n"
~"\nNon-debugging symbols:\n"
~"[2]    -[NSException raise]\n"
~"[3]    raise\n"
=read-one-line,prompt="> "

In our version of gdb the console interpreter really is the straight  
CLI console interpreter - this is required to get the "set  
interpreter" command to work.  So we had to invent another  
interpreter that did the proper quoting.  Anyway, this is what it  
would look like for you...

Jim

On May 30, 2006, at 10:41 AM, Jim Ingham wrote:

> For that we added a "command_line_input_hook" which we run at the  
> beginning of command_line_input in top.c.  We have an "mi running  
> cli" version that we put in place when we run -interpreter-exec.   
> This hook sends an async message like:
>
> (gdb) set interpreter mi1
> -interpreter-exec console "break raise"
> [0] cancel
> [1] all
>
> Non-debugging symbols:
> [2]    -[NSException raise]
> [3]    raise
> =read-one-line,prompt="> "
>
> When the UI gets this, it can put up the prompt, and then send the  
> next line of input when it gets one.  You have to do this not only  
> for the break command, but also so things like:
>
> -interpreter-exec console "define foo"
>
> and
>
> -interpreter-exec console "commands $bpnum"
>
> work properly.
>
> Looks like the hooks are all gone away from TOT gdb.  I'm not sure  
> what is supposed to replace them in instances like this.  But  
> anyway, something like this is what you will probably want to do.
>
> Jim
>
> On May 30, 2006, at 10:15 AM, Bob Rossi wrote:
>
>> On Tue, May 30, 2006 at 09:59:55AM -0700, Jim Ingham wrote:
>>> 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.
>>
>> What about the -interpreter-exec console "b A::func" case?
>>
>> Thanks,
>> Bob Rossi
>