From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27341 invoked by alias); 30 Jul 2010 18:57:59 -0000 Received: (qmail 27328 invoked by uid 22791); 30 Jul 2010 18:57:59 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 18:57:54 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 680894B06E; Fri, 30 Jul 2010 11:57:53 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id D20CCCD987; Fri, 30 Jul 2010 11:57:52 -0700 (PDT) Message-ID: <4C5320B0.2070309@vmware.com> Date: Fri, 30 Jul 2010 18:57:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Brian Heilig CC: "gdb@sourceware.org" Subject: Re: Porting gdb to Cyclops64 References: <1280510022.1560.20.camel@random> <4C530B30.1000603@vmware.com> <1280515973.1560.30.camel@random> In-Reply-To: <1280515973.1560.30.camel@random> Content-Type: text/plain; charset=UTF-8; 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: 2010-07/txt/msg00126.txt.bz2 Brian Heilig wrote: > 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? The default mode is synchronous debugging, which means that any time you are looking at the gdb prompt, the target is stopped. It would probably be easiest to implement that first and get it working, before attempting asynchronous mode. So yes, attaching with gdb should stop the target. > 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. You certainly don't have to implement everything all at once. Try this for a reference: http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html#Remote-Protocol