From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8316 invoked by alias); 5 May 2009 17:41:50 -0000 Received: (qmail 8308 invoked by uid 22791); 5 May 2009 17:41:49 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 May 2009 17:41:43 +0000 Received: (qmail 12349 invoked from network); 5 May 2009 17:41:41 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 May 2009 17:41:41 -0000 From: Pedro Alves To: "Marc Khouzam" Subject: Re: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux Date: Tue, 05 May 2009 17:41:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org References: <6D19CA8D71C89C43A057926FE0D4ADAA075CB605@ecamlmw720.eamcs.ericsson.se> <200905021814.26543.pedro@codesourcery.com> <6D19CA8D71C89C43A057926FE0D4ADAA071521E9@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA071521E9@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905051842.18379.pedro@codesourcery.com> 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/msg00019.txt.bz2 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 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 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 "". 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