From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2809 invoked by alias); 5 Aug 2010 14:19:56 -0000 Received: (qmail 2798 invoked by uid 22791); 5 Aug 2010 14:19:55 -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; Thu, 05 Aug 2010 14:19:48 +0000 Received: (qmail 26019 invoked from network); 5 Aug 2010 14:19:46 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Aug 2010 14:19:46 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Porting gdb to Cyclops64 Date: Thu, 05 Aug 2010 14:19:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.31-11-rt; KDE/4.4.2; x86_64; ; ) Cc: Brian Heilig References: <1280510022.1560.20.camel@random> <201008021435.16106.pedro@codesourcery.com> <1281016608.1560.79.camel@random> In-Reply-To: <1281016608.1560.79.camel@random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201008051519.39349.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-08/txt/msg00039.txt.bz2 On Thursday 05 August 2010 14:56:48, Brian Heilig wrote: > In my previous message I described a problem I encountered while > stepping a multi-threaded program. Here is a general description of > what's happening. > > All threads execute in parallel (on their own core) on the Cyclops64 > chip. I implemented a queue on the gdb server to serialize events. This > makes Cyclops64 look like a cooperatively scheduled architecture to gdb > in stop mode. > > While single stepping a single thread (let's call it thread 5) gdb > decided to set a breakpoint at some address and continue all threads. > All threads hit this internal breakpoint including thread 5. The > breakpoint events for threads 1-4 are reported and ignored by gdb (gdb > knows it doesn't care about these threads). Then thread 5 is reported > and gdb removes the breakpoint. However the event for threads 6-n are > still in the queue. The next time the user continues these events are > reported. Since gdb removed the internal breakpoint it assumes these > events must be caused by something else and doesn't filter them out. > > Is there anything I can do about this? Yes. I'll suggest two alternatives. #1 - before reporting a delayed/queued breakpoint hit event, check whether there's still a breakpoint still inserted where the thread is stopped. If there isn't, then just resume the thread without telling gdb about the stop. #2 - don't leave breakpoint hit events queued (all other events, yes, leave them). When you've stopped all threads to report a breakpoint hit to gdb, go through all threads, and those that have stopped due to a breakpoint, simply forget their breakpoint hits. The next time gdb resumes those threads, they'll immediately hit the same breakpoint again. You'll most likely want to add a bit of randomness to which of the threads amongs those that have hit a breakpoint you're going to report to gdb. #2 is what both native linux gdb and linux gdbserver implement nowadays. gdbserver used to implement #1 until recently. #1 has the advantage that it's a bit more efficient since it avoids resuming the target when not strictly necessary. The disadvantage is that it makes managing the PC adjustment after breakpoint traps more complicated. E.g., the stub needs extra care to present to GDB already adjusted PCs for all those threads that still have pending breakpoint hits to report to gdb in the event queue, but, to unadjust them when finally report the queued breakpoint hit, so that gdb itself does the necessary adjustment. This may not be a concern on Cyclops64, I don't know. > Is there a facility to set a > breakpoint for a single thread and filter them on the server? Nope, it's one of those IWBN things that nobody ever got around to working on, AFAIK. > Or is this > just a consequence of gdb not knowing how to deal with an SPMD > architecture yet? Nope. -- Pedro Alves