From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14228 invoked by alias); 16 Aug 2004 14:20:53 -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 14157 invoked from network); 16 Aug 2004 14:20:50 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 16 Aug 2004 14:20:50 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i7GEKn9u006684 for ; Mon, 16 Aug 2004 16:20:49 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Mon, 16 Aug 2004 16:18:52 +0200 Message-Id: <5.2.0.9.1.20040816154657.01ce05d0@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Mon, 16 Aug 2004 14:20:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: Thread-specific breakpoints In-Reply-To: <20040816132633.GA23408@nevyn.them.org> References: <5.2.0.9.1.20040816090919.01cefeb0@NT_SERVER> <5.2.0.9.1.20040816090919.01cefeb0@NT_SERVER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-08/txt/msg00217.txt.bz2 >> Is there support for thread-specific breakpoints in gdb? I couldn't see it >> in the interface/commands. If not, are there plans to add it to gdb? >> >> I know that other people have already tried to do so, e.g. SmartGDB >> http://hegel.ittc.ukans.edu/projects/smartgdb/brief.html >> >> But this a workaround with the help of tcl and only supports some >> thread libs. As I need support over a stub for a proprietary system >> (not Linux) this won't work. > >What features do you need from thread-specific breakpoints? It could >mean several things. > >The closest GDB comes is "break thread ". 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 bye Fabi