This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux
> -----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