From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10587 invoked by alias); 3 May 2009 02:30:24 -0000 Received: (qmail 10573 invoked by uid 22791); 3 May 2009 02:30:19 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS,WEIRD_PORT X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 03 May 2009 02:30:14 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n432UAGQ009501; Sat, 2 May 2009 21:30:11 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 May 2009 21:30:10 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux Date: Sun, 03 May 2009 02:30:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA071521E9@ecamlmw720.eamcs.ericsson.se> References: <6D19CA8D71C89C43A057926FE0D4ADAA075CB605@ecamlmw720.eamcs.ericsson.se> <200905021814.26543.pedro@codesourcery.com> From: "Marc Khouzam" To: "Pedro Alves" , 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/msg00010.txt.bz2 > > I'm using HEAD (from yesterday) with Non-Stop locally on Linux. > > I notice that when all my threads are running, setting a breakpoint > > is misbehaving. > > > > First, should I be able to set a breakpoint when all threads > > are running (on Linux)? >=20 > I've worked with non-stop mode in a few targets other than linux > already, and so far, only linux has this issue, and it > is *really* a nuisance. I've been thinking we should make it > possible on linux to insert breakpoints when threads are running > as well. The user experience is just bad otherwise. I very much agree with you.=20=20 =20 And that is really what we need on the frontend side. I'll probably have to force such a behavior (by suspending a thread, planting the bp, and resuming)=20 if GDB does not provide it directly. > > Either way though, setting a bp reports an error -with- > > a breakpoint id, and then 'info break' shows the breakpoint > > as being set. However, the breakpoint does not actually hit. > > > > See below for the session. > > > > (gdb) > > info b > > &"info b\n" > > ~"Num Type Disp Enb Address What\n" > > ~"1 breakpoint keep y 0x080485dc in main at > > MultiThread.cc:24\n" > > ~"2 breakpoint keep y 0x0804857a in thread_exec(void*) at > > MultiThread.cc:10\n" > > ~"3 breakpoint keep y 0x0804857e in thread_exec(void*) at > > MultiThread.cc:11\n" > > ^done > > > > =3D=3D Both 'failed' breakpoints show as installed, but they =3D=3D > > =3D=3D don't actually stop the thread. =3D=3D >=20 > I don't think this output indicates the breakpoints are installed or not. > "Enb" is a high level user setting; The "Address" field showing a resolve= d address > means that GDB is sure of the breakpoint address and believes those addre= sses > belong to currently mapped memory area --- if the breakpoints that failed > to insert pointed at code in a shared library, GDB would have made the > breakpoint locations pending (), because it would assume that > the reason the insertion failed was due to the shared library having > been unloaded. But, GDB doesn't do that for breakpoints set in > the main executable -- only in shlibs. I'm just surprised that GDB returns an ^error, and still shows the breakpoi= nt in the list. If the bp was I don't believe GDB would have return= ed an ^error. > What would people think of adding a new column in "info breakpoints" show= ing > 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. >=20 > E.g.: >=20 > 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. =20 Thanks =20 Marc =20