RE: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: Pedro Alves [mailto:pedro@codesourcery.com] 
> Sent: Tuesday, May 05, 2009 1:42 PM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: Setting breakpoint misbehaving with all threads 
> running in Non-Stop on Linux
> 
> On Sunday 03 May 2009 03:30:09, Marc Khouzam wrote:
> 
> > I'm just surprised that GDB returns an ^error, and still 
> shows the breakpoint
> > in the list.  If the bp was <PENDING> I don't believe GDB 
> would have returned
> > an ^error.
> 
> Yes, I see what you mean.  Hmmm, to understand the issue here, you
> have to realise that breakpoint handling is split in roughly two
> layers --- the logical/user/high-level breakpoints, and the
> physical/low-level breakpoint locations (the distinction isn't that
> pure in GDB's implementation, but still, it's there).
> 
> When in stock all-stop mode, you issue "break foo", only the
> high-level part is handled --- roughly, the breakpoint address is
> resolved, and the breakpoint is added to the breakpoint list. 
>  The command
> is completed at this point, and ends successfully.  The 
> breakpoints are
> only physically inserted in the target the next time you try to
> resume it, say with a "continue".  At this point, in all-stop mode, if
> the insertion fails, you'll see those errors in the console, which
> will cancel the "continue" command (remember that errors are 
> like java/c++
> exceptions in GDB) and leave the inferior stopped.  So, when 
> these kinds of
> errors happen, the 'break foo' command as long since been
> executed successfully.
> 
> In non-stop mode, however, (or with all-stop + 'set breakpoint
> always-inserted on'), the "breakpoint" command behaves a bit
> differently.  As soon as the logical high-level breakpoint
> is added to the breakpoint list, GDB tries to insert the physical
> breakpoints into the target, still before the "b foo" command 
> finishes.
> So, any error thrown while inserting the breakpoint in the target
> ends up as an "^error" return to the 'break command'.  Maybe this
> behaviour isn't correct, but it may be tricky to do otherwise.
> 

Thanks for this explanation, it made things much clearer for me.

Eclipse has a similar mechanism, where a blue dot is shown where
a breakpoint is set, and if the bp is properly installed, a check
mark is added.

The problem I have, if I understood your explanation properly,
is that GDB does not clearly tell the frontend if the breakpoint
is installed.  What I mean is, that if Eclipse shows a breakpoint
as not installed then it should never hit, and the reverse should
be true too.

But from what you wrote, it seems that GDB can report a failed
installation (in non-stop) and yet the bp will hit at some point
in the future, when installation succeeds.
From what I understand, the ^error or ^done following a -break-insert
does not really indicate if the breakpoint has been/will be installed
successfully.  A little like <PENDING>.

I guess this comes back to the need for a =breapoint-inserted/installed
event.  We need a way for the frontend to properly indicate to the user
if a bp should be expected to hit or not.

We have this same problem for <PENDING> because we don't have such an
event notifying the frontend that the breapoint is no longer Pending,
but has been installed.

I think my best bet is to show a bp that failed, as Uninstalled, and
wait for it to hit.  At that point, I can mark it as Installed.
This is a bit what we are planning to do for <PENDING> bp, except
that in that case, we can use the new =library-loaded events
as an indicator that some Pending bp might have just been installed
and update the UI.

> Since in non-stop mode, this exception isn't going to stop 
> the inferior
> from continuing to execute, perhaps the insertion errors
> should be downgraded to warnings (in non-stop mode only), and 
> GDB should
> return success indicating that the logical breakpoint was 
> created anyway?

At this point, I think this would be an improvement for frontends.
What I think we need is that
^error would mean bp failed permanently, while a successful answer
would need to differentiate between 'already installed' and
'may install in the future' which comes down to PENDING.
-break-insert already has an indicator for PENDING it is reply and
this situation could be treated the same, I think.

> > > What would people think of adding a new column in "info 
> breakpoints" showing
> > > the "inserted" status of the breakpoint?  It should be used to
> > > show 'inserted', 'not inserted', 'not inserted due to 
> error' state,
> > > and perhaps more states.
> > > 
> > > E.g.:
> > > 
> > >  Num     Type           Disp Enb Ins Address    What
> > > 1       breakpoint     keep y   y   0x080485dc in main at 
> MultiThread.cc:24
> >  > 2       breakpoint     keep y   n   <PENDING>  at foo
> > >  3       breakpoint     keep y   E   0xaaff8f45 at foo2
> > 
> > What is the value of have a bp shown with an Error?  Will 
> that bp ever
> > work?  Why should it be kept around?
> > What I noticed is that even after the main thread stops, in my test,
> > the failed bp still does not hit.  So, I'm wondering of it 
> usefulness.
> 
> I bet that if you *resume* the thread again after that stop, 
> the breakpoint
> would finally insert successfully.
> 
> I've worked with some remote targets that can refuse to insert
> breakpoints in some locations for whatever reasons.  If it 
> happens that
> the breakpoint is in a shared library, and because GDB 
> currently assumes
> that any error while inserting such breakpoints mean that the 
> corresponding
> shared library was unloaded, so it suppresses the insert 
> failed error message,
> and the "Address" field is displayed as "<PENDING>".
> I've had customers report that as confusing, since the 
> address location
> isn't pending at all, per the PENDING definition --- GDB knows well
> where it should be inserted, and, the shared library *is* mapped
> in.  If the breakpoint was set in the main code, as in your example, 
> than GDB is noisy when the user tries to insert such breakpoints, but
> the error out is transient and gets lost in the console log.
> Having an extra column would allow showing those breakpoint's 
> insertion
> states.  Another example is the case of the target 
> *temporarily* refusing
> to install breakpoints, telling GDB "not now, but at a later time they
> can be inserted".  I know Ulrich proposed adding such support for the
> multi-arch Cell debugger.  I'm thinking that such new column
> could "Ins" -> "nT" for "not inserted, target is refusing such
> breakpoints temporarily".
> 
> Hope I've made some sense.

Yes, thank you.
We don't really use the 'info break' output, as we have tried to rely
on MI and MI events only, so I have no preference about the suggested 
new column from a DSF-GDB point-of-view.

Thanks again.

Marc