From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2191 invoked by alias); 1 Sep 2011 13:23:51 -0000 Received: (qmail 2181 invoked by uid 22791); 1 Sep 2011 13:23:50 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Sep 2011 13:23:36 +0000 Received: from macserver.private ([77.57.184.28]) by ms9smtp.webland.ch (Webland Mail Server v10.0) with ASMTP id KWY12034 for ; Thu, 01 Sep 2011 15:23:34 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id AC1A4E033DC; Thu, 1 Sep 2011 15:23:24 +0200 (CEST) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRqZBDp+Gk5S; Thu, 1 Sep 2011 15:23:24 +0200 (CEST) Received: from [192.168.1.18] (unknown [192.168.1.18]) by macserver.private (Postfix) with ESMTP id C7AD9E033D1 for ; Thu, 1 Sep 2011 15:23:23 +0200 (CEST) Message-ID: <4E5F8753.8070003@indel.ch> Date: Thu, 01 Sep 2011 13:23:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Thread Specific Breakpoints in Remote Targets References: <201108311909.22045.pedro@codesourcery.com> In-Reply-To: <201108311909.22045.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: 2011-09/txt/msg00003.txt.bz2 On 31.08.2011 20:09, Pedro Alves wrote: > On Wednesday 31 August 2011 15:47:32, Tom Tromey wrote: >>>>>>> "Josh" == Josh Watt writes: >> Josh> As can been seen from the log, the stub is sending a message to >> Josh> switch to thread 1040 ($Hg410#44) right before setting the >> Josh> breakpoint (and again before deleting it). In subsequent >> Josh> operation, it is apparent that it is always switching to this >> Josh> thread when setting and clearing a breakpoint. >> >> FWIW I found your note very clear, thanks for the dump and background >> info. >> >> Josh> Because of this, our remote stub cannot rely on the currently >> Josh> selected thread as the target thread for a given breakpoint and >> Josh> must communicate with GDB every time a breakpoint is hit. >> >> I did not understand this though. >> >> It sounds like you are making breakpoints on the target thread-specific >> based on the current thread. But I thought we didn't (yet) have a way >> to inform the target that a given breakpoint was thread-specific (but I >> don't know this area extremely well -- if I'm wrong I'd like to know >> about it). > You're right, we don't. Just to mention that: My company would be very interested in (optional) 'thread specific breakpoints' support for remote targets. gdb could ask a gdbstub whether it supports this feature (by the qSupported packet). In our case, our proprietary real-time OS already offers support for 'thread specific breakpoints' and it is definitely not an option for our system to use the 'thread specific breakpoint emulation' performed by the gdb frontend today as it would disrupt real-time behavior. The lack of this feature causes major troubles for us during single-stepping, where temporary (global) breakpoints are set by the gdb frontend... to circumvent this "problem", I had to slightly extend the remote protocol for real 'thread specific breakpoints' (I just added a new breakpoint type (5) that also passes the Pid/Tid to the stub and which is used during step operations). I really hope we can make this feature (however it'll be implemented) part of the original gdb sometime in the future! > >> I think it would be preferable to >> implement real target support for thread-specific breakpoints. > Very much. > > Also: > >> Sending packet: $vCont?#49...Ack >> Packet received: >> Packet vCont (verbose-resume) is NOT supported > ... >> Sending packet: $s#73...Ack > ... > > Please implement vCont support in your stub. s and c > are deprecated on multi-threaded targets. There's no > way to make them work correctly in some cases. >