From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4450 invoked by alias); 24 Jan 2006 23:35:17 -0000 Received: (qmail 4442 invoked by uid 22791); 24 Jan 2006 23:35:16 -0000 X-Spam-Check-By: sourceware.org Received: from BISCAYNE-ONE-STATION.MIT.EDU (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jan 2006 23:35:13 +0000 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k0ONYf2Z017512; Tue, 24 Jan 2006 18:34:41 -0500 (EST) Received: from contents-vnder-pressvre.mit.edu (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.7.16.67]) (authenticated bits=56) (User authenticated as nathanw@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k0ONYcSi022780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jan 2006 18:34:39 -0500 (EST) Received: (from nathanw@localhost) by contents-vnder-pressvre.mit.edu (8.12.9) id k0ONYcQa000539; Tue, 24 Jan 2006 18:34:38 -0500 (EST) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: vCont [was Re: Multithreaded debugging: strange thread switches] References: <200601231820.33372.ghost@cs.msu.su> <20060123155240.GA16524@nevyn.them.org> From: "Nathan J. Williams" Date: Wed, 25 Jan 2006 00:04:00 -0000 In-Reply-To: <20060123155240.GA16524@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00248.txt.bz2 Daniel Jacobowitz writes: > This, generally, is part of the problem. If you want this to work, you > need to implement the vCont packet in the stub. The Hc1 packet is > supposed to mean "step only thread 1, leaving thread 2 stopped", and > that's not what the gdb "next" command is supposed to map to - that's > "step this thread but leave other threads free-running". Tangentially... I'm working on a stub for a system that doesn't have hardware single-step; GDB knows that and doesn't try to issue any step commands. However, the logic in remote.c that analyzes the response to the vCont? packet refuses to use vCont unless it supports all of s, S, c, and C. Is the best thing for my stub just to lie about supporting s and S, and to rely on the knowledge that GDB won't try to use them? - Nathan