From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30860 invoked by alias); 4 Mar 2011 10:05:07 -0000 Received: (qmail 30816 invoked by uid 22791); 4 Mar 2011 10:05:05 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_BJ X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Mar 2011 10:05:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 820F92BB1C3; Fri, 4 Mar 2011 05:04:58 -0500 (EST) 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 ZeqlZYfHiTGs; Fri, 4 Mar 2011 05:04:58 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0E3632BB1C2; Fri, 4 Mar 2011 05:04:57 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 531781459AD; Fri, 4 Mar 2011 14:04:34 +0400 (RET) Date: Fri, 04 Mar 2011 10:05:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: Add support for VxWorks (v3) Message-ID: <20110304100434.GG30306@adacore.com> References: <1299219720-13398-1-git-send-email-brobecker@adacore.com> <201103040936.02472.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103040936.02472.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00280.txt.bz2 > I haven't really looked at the code yet, but, the question > I think should be answered most importantly, is: do you > really need partitions at all? Unfortunately, you do. The most common case is when you are debugging in system mode. This essentially means debugging the entire system, and therefore multiple partitions. Another use case is is when debugging a task that runs some code provided by a shared partition. It's a little bit like shared libraries on traditional OSes. In that case, you're effectively debugging over several partitions at the same time. I should also repeat that the partition-switching implementation has been stubbed out (meaning not contributed yet). The reason for that is that it makes some assumptions about how core GDB accesses its objfiles. I was under quite a bit of pressure when I implemented this, and the good news is that it's localized, and never broke in the years since I wrote the code. I'm keeping my fingers crossed. But what it does is rebuild GDB's objfile list at each partition switch. This allows us to give the user the same visibility rules as the code running loaded in that partition. I have some ideas of how I would like to integrate that concept in GDB. There are two issues: (1) we need one list of objfiles per partition - that should be relatively easy to deal with; (2) we have some partitions that are a little special: (2a) the "kernel" partition, which is a partition accessible from all other partitions; (2b) shared partitions, which can be accessible from other partitions, provided that the shared partition is in the "link path" of the client partition (it's an ordered list of shared partitions). I think we can deal with the "kernel" partition as being an implicit shared partition - that would be dealt with at the target level. But we will need to teach the objfile walking about link paths (not very hard, I expect). If cell or any other target could benefit from partitions as well, I'd be happy to start designing this part sooner rather than later. I sent an RFC about that many months ago, and got no reply, so I just assumed little interest. But it would be nice to design this part with someone else - so far, it's been pretty much me. -- Joel