MI and pending breakpoints

[Jim Ingham]

On Mar 15, 2006, at 8:40 AM, Bob Rossi wrote:

> On Wed, Mar 15, 2006 at 08:34:55AM -0800, Jim Ingham wrote:
>>
>> On Mar 15, 2006, at 8:21 AM, Bob Rossi wrote:
>>
>>> On Wed, Mar 15, 2006 at 08:19:59AM -0800, Jim Ingham wrote:
>>>> You need to set the gdb variable "pending" to "on" before  
>>>> setting the
>>>> breakpoint.  Since this is kind of a pain, we added a "-f" option
>>>> to -
>>>> break-insert that will do this for you wrapped around the  
>>>> breakpoint
>>>> setting ("-f" because this feature was called "future-break" in the
>>>> NeXT gdb many years ago.)
>>>>
>>>> It's also arguable that for -break-insert you ALWAYS want "pending"
>>>> to be "on".
>>>
>>> That's how annotate=2 works. However, I think GDB should query the
>>> user
>>> the same way it does from the CLI. It's wierd when people start
>>> using my
>>> front end and ask why it behaves differently than the CLI.
>>
>> Not sure I agree with this.  AFAICT, the main reason for asking the
>> user is that you can easily mis-type a file:line spec, and it's good
>> to have the CLI tell you this didn't set so you can check your
>> spelling.  But this should not be possible for the most common type
>> of breakpoint in a UI, which is clicking in the gutter of an editor
>> window.
>>
>> I think having the UI query would be disruptive...
>
> OK, I understand what you mean, and sort of agree. I assume you are
> talking about when the GUI issues the command for the breakpoint based
> on some interaction with the user. I think that the FE should be fully
> aware of the fact that the breakpoint will be pending. GDB should  
> query
> the FE (in the MI sense) and the FE can alert the user if it  
> chooses, or
> simply always set the breakpoint. This provides the most  
> flexibility. I
> would only expect this query to happen if the 'set' variable for that
> says it should be queried. The user may want to know if it's  
> pending or
> not. Also, a nice feature would be to add this to the breakpoint MI
> output data if it's not already there.
>
> Here is the situation I'm talking about. When the user types 'b
> file:line' in the console that the FE provides them, and they do  
> not get
> a query back from GDB when using annotate=2. It simply always set's  
> the
> breakpoint. I don't know if MI currently works the same.

If the breakpoint isn't successfully set, the breakpoint address is  
set to "<PENDING>".  This is part of the MI -break-insert return  
value.  So the UI can tell whether it was set or not.  If the UI  
wanted to do anything special, it could ask the user itself about  
this breakpoint, and if the user didn't want it, the UI could just  
delete it.  We haven't had any requests for this behavior, however.

Xcode does have a "breakpoints" window that indicates a bunch of  
things about the breakpoint, including whether it has been set yet or  
not.  That's the way we've handled this.

Jim

>
> Bob Rossi