From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13009 invoked by alias); 31 Aug 2011 18:09:42 -0000 Received: (qmail 12989 invoked by uid 22791); 31 Aug 2011 18:09:41 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Aug 2011 18:09:25 +0000 Received: (qmail 4124 invoked from network); 31 Aug 2011 18:09:24 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Aug 2011 18:09:24 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Thread Specific Breakpoints in Remote Targets Date: Wed, 31 Aug 2011 18:09:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.0; x86_64; ; ) Cc: Tom Tromey , Josh Watt References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108311909.22045.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: 2011-08/txt/msg00134.txt.bz2 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. > 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. -- Pedro Alves