From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23833 invoked by alias); 2 May 2009 17:14:36 -0000 Received: (qmail 23824 invoked by uid 22791); 2 May 2009 17:14:35 -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; Sat, 02 May 2009 17:14:30 +0000 Received: (qmail 7718 invoked from network); 2 May 2009 17:14:28 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2009 17:14:28 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Setting breakpoint misbehaving with all threads running in Non-Stop on Linux Date: Sat, 02 May 2009 17:14:00 -0000 User-Agent: KMail/1.9.10 Cc: "Marc Khouzam" References: <6D19CA8D71C89C43A057926FE0D4ADAA075CB605@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA075CB605@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905021814.26543.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/msg00009.txt.bz2 On Friday 01 May 2009 20:31:21, Marc Khouzam wrote: > 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)? 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. > 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 > > == Both 'failed' breakpoints show as installed, but they == > == don't actually stop the thread. == 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 resolved address means that GDB is sure of the breakpoint address and believes those addresses 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. 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 ? -- Pedro Alves