From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10686 invoked by alias); 5 Aug 2010 13:56:58 -0000 Received: (qmail 10400 invoked by uid 22791); 5 Aug 2010 13:56:56 -0000 X-SWARE-Spam-Status: No, hits=-1.3 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; Thu, 05 Aug 2010 13:56:50 +0000 Received: from [192.168.9.69] (random.xmen.eti [192.168.9.69]) (Authenticated sender: bheilig) by etinternational.com (Postfix) with ESMTPSA id DCA66F00D0 for ; Thu, 5 Aug 2010 09:56:48 -0400 (EDT) Subject: Re: Porting gdb to Cyclops64 From: Brian Heilig To: gdb@sourceware.org In-Reply-To: <201008021435.16106.pedro@codesourcery.com> References: <1280510022.1560.20.camel@random> <201007310017.53475.pedro@codesourcery.com> <1280755494.1560.47.camel@random> <201008021435.16106.pedro@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 05 Aug 2010 13:56:00 -0000 Message-ID: <1281016608.1560.79.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-08/txt/msg00038.txt.bz2 Dear list, 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? Is there a facility to set a breakpoint for a single thread and filter them on the server? Or is this just a consequence of gdb not knowing how to deal with an SPMD architecture yet? Thank You, Brian