From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21617 invoked by alias); 30 Jul 2010 18:53:01 -0000 Received: (qmail 21607 invoked by uid 22791); 30 Jul 2010 18:53:00 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from etinternational-gw.customer.alter.net (HELO etinternational.com) (63.125.108.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 18:52:55 +0000 Received: from [192.168.9.69] (random.xmen.eti [192.168.9.69]) (Authenticated sender: bheilig) by etinternational.com (Postfix) with ESMTPSA id 670C1138101 for ; Fri, 30 Jul 2010 14:52:53 -0400 (EDT) Subject: Re: Porting gdb to Cyclops64 From: Brian Heilig To: "gdb@sourceware.org" In-Reply-To: <4C530B30.1000603@vmware.com> References: <1280510022.1560.20.camel@random> <4C530B30.1000603@vmware.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 30 Jul 2010 18:53:00 -0000 Message-ID: <1280515973.1560.30.camel@random> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2010-07/txt/msg00125.txt.bz2 On Fri, 2010-07-30 at 10:26 -0700, Michael Snyder wrote: > Brian Heilig wrote: > > > > Does gdb support the operation 'step the current thread and leave all > > other threads stopped'? > > Yes, see "set scheduler-locking". > > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gdb/thread-stops.html > Thank you. When I attach to my remote target, if the target is running (not stopped at a breakpoint) gdb currently doesn't know it and presents the gdb prompt as if the inferior were stopped. Clearly I've not implemented the protocol correctly in this case. Should I stop the inferior when the client is attached? Or should I send a response from my target that will indicate to gdb that it is currently running? Is there a reference for the most recent remote protocol? I'm sure I've only implemented a small subset of the protocol, and that probably isn't %100 correct. Thanks again, Brian