From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6979 invoked by alias); 4 Mar 2011 10:45:21 -0000 Received: (qmail 6968 invoked by uid 22791); 4 Mar 2011 10:45:20 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_BJ,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; Fri, 04 Mar 2011 10:45:13 +0000 Received: (qmail 31426 invoked from network); 4 Mar 2011 10:45:12 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Mar 2011 10:45:12 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: Add support for VxWorks (v3) Date: Fri, 04 Mar 2011 10:45:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.6.0; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <1299219720-13398-1-git-send-email-brobecker@adacore.com> <201103040936.02472.pedro@codesourcery.com> <20110304100434.GG30306@adacore.com> In-Reply-To: <20110304100434.GG30306@adacore.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103041045.10426.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00283.txt.bz2 On Friday 04 March 2011 10:04:34, Joel Brobecker wrote: > > 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. Not sure I understand the use case completely. 1) Could map into a single inferior and then "info sharedlibrary" lists all partitions? What is it in the use case that makes this not viable? or, 2) Could map each partition into an inferior? What is it in the use case that makes this not viable? Again, note I'm not saying there's no space for something like partitions, but if there is, I'd much rather it was for the right reasons, and I'd like to understand what does it bring that the current model doesn't support. > 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. So that task would be mapped to a running inferior, and the shared partition would appear under shared libraries? > 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. If we end up with partitions, note that the "program space" entity was designed specifically for this. From your description, the partition's symbols are a natural fit for a "program space". I kept the "address space" object separate from the "program space" exactly for cases like these, where you have several distinct programs (program spaces / partitions) running under the same address space. You shouldn need objfile list swapping hacks anymore. > 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). -- Pedro Alves