From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27347 invoked by alias); 30 Aug 2010 19:44:42 -0000 Received: (qmail 27333 invoked by uid 22791); 30 Aug 2010 19:44:41 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_50 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; Mon, 30 Aug 2010 19:44:38 +0000 Received: from [192.168.9.69] (random.xmen.eti [192.168.9.69]) (Authenticated sender: bheilig) by etinternational.com (Postfix) with ESMTPSA id 1F52BF00E0 for ; Mon, 30 Aug 2010 15:44:36 -0400 (EDT) Subject: Cyclops64 Multi-Process From: Brian Heilig To: gdb@sourceware.org In-Reply-To: <201008051519.39349.pedro@codesourcery.com> References: <1280510022.1560.20.camel@random> <201008021435.16106.pedro@codesourcery.com> <1281016608.1560.79.camel@random> <201008051519.39349.pedro@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 30 Aug 2010 19:44:00 -0000 Message-ID: <1283197475.1541.18.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/msg00166.txt.bz2 Dear list, I have successfully ported gdb 7.1 to Cyclops64 and it is quite stable. My next task is to implement multi-processor debugging for use in a super computer. There can be many processors connected through some interface, each processor having many parallel threads, and all of them executing the same program. It would be easy for me to allow gdb to assign a thread id to each thread on every processor as the stop event arrives. But there can be 100,000+ threads and users tend to think of each thread in terms of the node that it executes on. Therefore the multiprocess extensions of gdb seemed like a nice fit because of the 'process.thread' syntax. The gdb client accepts the stop events for the first pid, but any stop event thereafter causes the following error: "internal-error: Can't determine the current address space of thread Thread 2.1" Do you think shoehorning multiprocess extensions into my multi processor system is a good idea? Is there something I can manipulate in the protocol to make the gdb client happy? Thank you, Brian