From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21536 invoked by alias); 30 Jul 2010 22:54:47 -0000 Received: (qmail 21527 invoked by uid 22791); 30 Jul 2010 22:54:47 -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 22:54:42 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 710DD30006; Fri, 30 Jul 2010 15:54:41 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost4.vmware.com (Postfix) with ESMTP id 67252C9A17; Fri, 30 Jul 2010 15:54:41 -0700 (PDT) Message-ID: <4C535831.8090000@vmware.com> Date: Fri, 30 Jul 2010 22:54: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> <4C5320B0.2070309@vmware.com> <1280521733.1560.44.camel@random> In-Reply-To: <1280521733.1560.44.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/msg00132.txt.bz2 Brian Heilig wrote: > On Fri, 2010-07-30 at 11:57 -0700, Michael Snyder wrote: >> 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. > > Thanks again Michael. > > Since all threads execute in parallel, more than one thread can hit a > breakpoint. In stop mode I should stop all threads when the first thread > hits a breakpoint. While stopping all threads other threads might hit a > breakpoint. My intention is to queue these "events" and report them in > sequential order to gdb. So that, in stop mode, when gdb tells the > target to continue it will actually dequeue the next event. If there are > no events then it will continue. Does this sound correct? That's very similar to the way it works on native Linux. Not because of true parallelism, but because we can't really stop all the threads and start them again simultaneously. > I guess I will have to implement non-stop mode as well since many > threads can hit a breakpoint. It would be very inconvenient for my user > to have to continue each thread individually. In this case I will not > queue events but rather just send them to gdb and let gdb sort them out. > Is this correct as well? I'm not sure -- maybe someone else will care to jump in.