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

[Pedro Alves <pedro at codesourcery dot com>]

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.

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?

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

-- 
Pedro Alves