From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16351 invoked by alias); 16 Aug 2004 14:24:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16338 invoked from network); 16 Aug 2004 14:24:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 16 Aug 2004 14:24:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BwiP5-0006dg-39; Mon, 16 Aug 2004 10:24:03 -0400 Date: Mon, 16 Aug 2004 14:24:00 -0000 From: Daniel Jacobowitz To: Fabian Cenedese Cc: gdb@sources.redhat.com Subject: Re: Thread-specific breakpoints Message-ID: <20040816142403.GA25458@nevyn.them.org> Mail-Followup-To: Fabian Cenedese , gdb@sources.redhat.com References: <5.2.0.9.1.20040816090919.01cefeb0@NT_SERVER> <5.2.0.9.1.20040816090919.01cefeb0@NT_SERVER> <5.2.0.9.1.20040816154657.01ce05d0@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.1.20040816154657.01ce05d0@NT_SERVER> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00218.txt.bz2 On Mon, Aug 16, 2004 at 04:20:39PM +0200, Fabian Cenedese wrote: > Yes, that's along the lines I was thinking. And after intense looking I even > found it in the manual. I missed it the first time as the break command > is explained in 5.1.1 whereas break thread by itself > is in 5.4. > > After looking at the communication with the stub it seems that the Z0 > packet only informs the stub about a breakpoint but not about the thread. > So every thread will stop here and gdb needs to tell them to continue > it it's not the wanted one. That could generate quite a lot of communication > (important if it's a serial connection) and also changes the timing quite > a lot. If the breakpoint handling was in the stub the stop'n'go could be > made much faster without the interaction of gdb. I guess if there is no > other possibility I could use the "monitor" command to inform the stub > about the thread of the breakpoint. But then again this is difficult as the > breakpoints are only set once a "step" or "continue" is sent... > > Thanks for the help anyway Yes, there's no way to set remote-assisted thread-specific breakpoints in the remote protocol. This might be a good thing to add. -- Daniel Jacobowitz