From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13146 invoked by alias); 30 Jul 2010 23:18:14 -0000 Received: (qmail 13136 invoked by uid 22791); 30 Jul 2010 23:18:13 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 23:17:57 +0000 Received: (qmail 4676 invoked from network); 30 Jul 2010 23:17:55 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Jul 2010 23:17:55 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Porting gdb to Cyclops64 Date: Fri, 30 Jul 2010 23:18:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; x86_64; ; ) Cc: Brian Heilig References: <1280510022.1560.20.camel@random> <4C5320B0.2070309@vmware.com> <1280521733.1560.44.camel@random> In-Reply-To: <1280521733.1560.44.camel@random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201007310017.53475.pedro@codesourcery.com> 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/msg00133.txt.bz2 On Friday 30 July 2010 21:28:53, Brian Heilig wrote: > 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? It does. Only a little care should be taken to dequeue events for threads that gdb is actually interested in. Say, while stepping all threads, some of the other threads hit breakpoints. The next time the user continues, gdb will want to step over the breakpoint that the thread had reported being hit. So, gdb removes this breakpoint and tells that single thread to single-step over this location. At this point, gdb hadn't told any of the other threads to resume, so you shouldn't dequeue any pending event for them yet. (the same needs considering if the user switches on scheduler-locking and resumes only one thread --- your target should not report pending events for threads that hadn't been resumed) (this is what the lwp->resumed flag in gdb/linux-nat.c or 'struct thread_info'->last_resume_kind in gdb/gdbserver/server.c implement) > 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? Not sure what you mean --- the user would still have to resume each thread individually. But yes, in non-stop mode, your target should let the other threads that hadn't hit any breakpoint continue running free. -- Pedro Alves