From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12206 invoked by alias); 5 May 2009 19:30:16 -0000 Received: (qmail 12149 invoked by uid 22791); 5 May 2009 19:30:10 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 May 2009 19:30:01 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n45Jdv4k019618; Tue, 5 May 2009 14:39:58 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 14:29:57 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux Date: Tue, 05 May 2009 19:30:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA0762F06E@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200905051842.18379.pedro@codesourcery.com> References: <6D19CA8D71C89C43A057926FE0D4ADAA075CB605@ecamlmw720.eamcs.ericsson.se> <200905021814.26543.pedro@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA071521E9@ecamlmw720.eamcs.ericsson.se> <200905051842.18379.pedro@codesourcery.com> From: "Marc Khouzam" To: "Pedro Alves" Cc: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00020.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:pedro@codesourcery.com]=20 > Sent: Tuesday, May 05, 2009 1:42 PM > To: Marc Khouzam > Cc: gdb@sourceware.org > Subject: Re: Setting breakpoint misbehaving with all threads=20 > running in Non-Stop on Linux >=20 > On Sunday 03 May 2009 03:30:09, Marc Khouzam wrote: >=20 > > I'm just surprised that GDB returns an ^error, and still=20 > shows the breakpoint > > in the list. If the bp was I don't believe GDB=20 > would have returned > > an ^error. >=20 > 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). >=20 > 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.=20 > The command > is completed at this point, and ends successfully. The=20 > 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=20 > like java/c++ > exceptions in GDB) and leave the inferior stopped. So, when=20 > these kinds of > errors happen, the 'break foo' command as long since been > executed successfully. >=20 > 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=20 > 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. >=20 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. =46rom 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 . I guess this comes back to the need for a =3Dbreapoint-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 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 bp, except that in that case, we can use the new =3Dlibrary-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=20 > the inferior > from continuing to execute, perhaps the insertion errors > should be downgraded to warnings (in non-stop mode only), and=20 > GDB should > return success indicating that the logical breakpoint was=20 > 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=20 > breakpoints" showing > > > the "inserted" status of the breakpoint? It should be used to > > > show 'inserted', 'not inserted', 'not inserted due to=20 > error' state, > > > and perhaps more states. > > >=20 > > > E.g.: > > >=20 > > > Num Type Disp Enb Ins Address What > > > 1 breakpoint keep y y 0x080485dc in main at=20 > MultiThread.cc:24 > > > 2 breakpoint keep y n at foo > > > 3 breakpoint keep y E 0xaaff8f45 at foo2 > >=20 > > What is the value of have a bp shown with an Error? Will=20 > 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=20 > usefulness. >=20 > I bet that if you *resume* the thread again after that stop,=20 > the breakpoint > would finally insert successfully. >=20 > I've worked with some remote targets that can refuse to insert > breakpoints in some locations for whatever reasons. If it=20 > happens that > the breakpoint is in a shared library, and because GDB=20 > currently assumes > that any error while inserting such breakpoints mean that the=20 > corresponding > shared library was unloaded, so it suppresses the insert=20 > failed error message, > and the "Address" field is displayed as "". > I've had customers report that as confusing, since the=20 > 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,=20 > 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=20 > insertion > states. Another example is the case of the target=20 > *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". >=20 > 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=20 new column from a DSF-GDB point-of-view. Thanks again. Marc