From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 558 invoked by alias); 31 Aug 2011 14:47:50 -0000 Received: (qmail 529 invoked by uid 22791); 31 Aug 2011 14:47:48 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Aug 2011 14:47:35 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7VElX4M021151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2011 10:47:34 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7VElXL5005096; Wed, 31 Aug 2011 10:47:33 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p7VElWjt023496; Wed, 31 Aug 2011 10:47:32 -0400 From: Tom Tromey To: Josh Watt Cc: gdb@sourceware.org Subject: Re: Thread Specific Breakpoints in Remote Targets References: Date: Wed, 31 Aug 2011 14:47:00 -0000 In-Reply-To: (Josh Watt's message of "Tue, 30 Aug 2011 17:03:02 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00133.txt.bz2 >>>>> "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). Josh> I looked through some of the code, and I think it is due to the Josh> following: Josh> In breakpoint.c there are calls to Josh> switch_to_program_space_and_thread() at lines 1895 and 2662 which Josh> must be selecting the wrong thread, but I'm not sure how to make Josh> it select the correct thread (if it is even supposed to). I think you are correct. switch_to_program_space_and_thread selects the first (meaning first in gdb's internal table) live thread of the first inferior bound to that program space. I am not sure whether this choice particularly matters to all callers of switch_to_program_space_and_thread. However, I think it probably does not matter to callers from breakpoint.c; I think those could safely short-circuit switching if the current program space is already correct and if the current thread is live. This, I think, will fix your immediate problem but I can't claim the result will really be correct. I think it would be preferable to implement real target support for thread-specific breakpoints. Tom