From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14960 invoked by alias); 18 Aug 2004 11:57:12 -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 14951 invoked from network); 18 Aug 2004 11:57:10 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 18 Aug 2004 11:57:10 -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 i7IBv99u025103 for ; Wed, 18 Aug 2004 13:57:09 +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 ; Wed, 18 Aug 2004 13:55:38 +0200 Message-Id: <5.2.0.9.1.20040818135647.01d11170@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Wed, 18 Aug 2004 11:57:00 -0000 To: gdb@sources.redhat.com From: Fabian Cenedese Subject: Re: Thread-specific breakpoints 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/msg00232.txt.bz2 Hmpf, sorry for the private mail. Now also to the list. >> 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. What about reading them back? Our embedded system is "intelligent" (yeah, I know) and has its own breakpoint handling for various reasons (performance, usability, security if the debugger dies...). So if we attach to a running target we first read the available breakpoints from the system. I think this is not only missing in the protocol but in gdb in general. Thanks bye Fabi