From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16881 invoked by alias); 21 Jul 2008 17:39:53 -0000 Received: (qmail 16872 invoked by uid 22791); 21 Jul 2008 17:39:53 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Jul 2008 17:39:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B9C2B2A9728; Mon, 21 Jul 2008 13:39:33 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Zdbw-sqsk2l1; Mon, 21 Jul 2008 13:39:33 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6AAB12A9668; Mon, 21 Jul 2008 13:39:33 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 4F107E7ACD; Mon, 21 Jul 2008 10:39:31 -0700 (PDT) Date: Mon, 21 Jul 2008 17:57:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: stanshebs@earthlink.net, gdb@sourceware.org Subject: Re: Towards multiprocess GDB Message-ID: <20080721173931.GA3859@adacore.com> References: <4880FFA8.3080600@earthlink.net> <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.4.2.2i 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: 2008-07/txt/msg00240.txt.bz2 > Please remind me, why was this a desirable capability again? One case that Pedro and I discussed at the GCC Summit when he mentioned this topic was VxWorks systems. AdaCore recently re-implemented support for ppc/vxworks targets in GDB, and I can post the diff if anyone is interested. I haven't done so yet, because there are a couple of major hacks that we had to introduced and I want to re-implement then appropriately before considering a submission. VxWorks introduces the notion of partitions, but has no notion of "process" - only "tasks" (aka threads). All tasks within a partition have access to everything within that partition. However, partitions can almost be viewed as different computers, so symbols in one partition are completely irrelevant to other partitions. One way to debug some of the code is to debug one task, and treat it as a process. But the reality is that programs are often multi-threaded and so debugging one task would only be debugging part the program. This is why we introduced the option of debugging the entire partition as one process. But most of our users want to debug the entire system rather than each individual task separately, because of inter-partition scheduling or communication issues. This is when the fun starts, because we now have symbols for one partition, and symbols for another partition, and we need to remember which partition they are for. I believe that adding support for multi-process debugging will solve the issue above, since each process should have its own list of objfiles and associated symbols. VxWorks also has the concept of shared-library partitions that any given partition can link to, effectively giving access to the symbols there. I think this is very comparable to shared libraries in Unix systems or DLLs on Windows. It would be really nice if we eventually taught GDB to recognize that two processes were using the same shared library and thus internally loaded the symbol once. -- Joel