MI and pending breakpoints

MI and pending breakpoints

[Vladimir Prus]

   
Hello!
I've got some problems with "pending breakpoints" functionality, using MI
interface. Here's example session:

   (gdb) break helper.cpp:4 
   break helper.cpp:4
   No source file named helper.cpp.
   Breakpoint 2 (helper.cpp:4) pending.
   ^done
   (gdb) -break-insert helper.cpp:5 
   No source file named helper.cpp.
   ^done

The CLI command correctly adds pending breakpoint. The helper.cpp file is in
dlopen-ed shared library, and the breakpoint will be resolved when the
library is loaded.

The MI command neither errors out (the reply is "^done", not "^error"), nor
it does anything. It does not report breakpoint number, it does not add any
breakpoint at all.

What is the reason for this? Is this a bug? How do other frontend authors
deal with breakpoints in shared libraries, then?

Thanks in advance,
Volodya

Re: MI and pending breakpoints

[Jim Ingham]

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

Jim

On Mar 15, 2006, at 4:25 AM, Vladimir Prus wrote:

>
> Hello!
> I've got some problems with "pending breakpoints" functionality,  
> using MI
> interface. Here's example session:
>
>    (gdb) break helper.cpp:4
>    break helper.cpp:4
>    No source file named helper.cpp.
>    Breakpoint 2 (helper.cpp:4) pending.
>    ^done
>    (gdb) -break-insert helper.cpp:5
>    No source file named helper.cpp.
>    ^done
>
> The CLI command correctly adds pending breakpoint. The helper.cpp  
> file is in
> dlopen-ed shared library, and the breakpoint will be resolved when the
> library is loaded.
>
> The MI command neither errors out (the reply is "^done", not  
> "^error"), nor
> it does anything. It does not report breakpoint number, it does not  
> add any
> breakpoint at all.
>
> What is the reason for this? Is this a bug? How do other frontend  
> authors
> deal with breakpoints in shared libraries, then?
>
> Thanks in advance,
> Volodya
>
>
>

Re: MI and pending breakpoints

[Bob Rossi]

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.

Bob Rossi

Re: MI and pending breakpoints

[Vladimir Prus]

On Wednesday 15 March 2006 19:19, Jim Ingham wrote:
> You need to set the gdb variable "pending" to "on" before setting the
> breakpoint.  

Do you mean:

   set breakpoint pending on

? That's what I do (not shown in the example), and without it the ordinary 
"break" won't set the breakpoint -- it will ask if pending breakpoint should 
be set. But even with it, "-break-insert" refused to set pending breakpoint.

Maybe, there's was bug that's fixed on Apple branch?

In fact, with CVS HEAD version, -break-insert calls gdb_breakpoint, which 
calls do_captured_parse_breakpoint which reports that file does not exists, 
and process stops (see breakpoint.c:gdb_breakpoint and 
mi/mi-cmd-break.c:mi_cmd_break_insert).

For "break", the do_captures_parse_breakpoint" is called as well, but after 
then, an explicit check for not found file is made, and pending breakpoint is 
added (see breakpoint.c:break_command_1)

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

Yes, this might be good.

- Volodya

Re: MI and pending breakpoints

[Jim Ingham]

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

Jim

Re: MI and pending breakpoints

[Jim Ingham]

I thought that would work, but as I said, we don't do it that way, we  
do:

-break-insert -f

which turns the pending on automatically.  I think that's a much more  
convenient way to do it...

Jim

On Mar 15, 2006, at 8:29 AM, Vladimir Prus wrote:

> Do you mean:
>
>    set breakpoint pending on
>
> ? That's what I do (not shown in the example), and without it the  
> ordinary
> "break" won't set the breakpoint -- it will ask if pending  
> breakpoint should
> be set. But even with it, "-break-insert" refused to set pending  
> breakpoint.
>
> Maybe, there's was bug that's fixed on Apple branch?

Re: MI and pending breakpoints

[Bob Rossi]

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.

Bob Rossi

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

Re: MI and pending breakpoints

[Nick Roberts]

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

and

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

AFAICT -annotate=2 doesn't change the behaviour of setting breakpoints.
After all, its just CLI with markup, not a separate interpreter like MI.


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

Re: MI and pending breakpoints

[Vladimir Prus]

[this message was originally sent off-list by mistake, reposting to list now]

On Wednesday 15 March 2006 19:37, you wrote:
> I thought that would work, but as I said, we don't do it that way, we
> do:
>
> -break-insert -f
>
> which turns the pending on automatically.  I think that's a much more
> convenient way to do it...

Any way, I've just looked at Apple code, and it considerable differs in 
'-break-insert' handling.

In CVS HEAD, gdb_breakpoint calls do_captured_parse_breakpoint, and exits.

In Apple version, gdb_breakpoint calls break_command_2 which calls 
do_captured_parse_breakpoint and then specially deals with pending 
breakpoints.

So, would it be a good idea to port/mimic Apple's changes? 
In fact, even if I port them I'll still need to workaround this bug on 
KDevelop side, but anyway, what about porting the fixes?

- Volodya