From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21273 invoked by alias); 26 Jun 2007 23:39:26 -0000 Received: (qmail 21264 invoked by uid 22791); 26 Jun 2007 23:39:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Jun 2007 23:39:22 +0000 Received: (qmail 16231 invoked from network); 26 Jun 2007 23:39:20 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jun 2007 23:39:20 -0000 To: Michael Eager Cc: gdb@sources.redhat.com Subject: Re: Non-uniform address spaces References: <467D4AE3.7020505@eagercon.com> <20070623212557.GB3448@caradoc.them.org> <467D9503.9060804@eagercon.com> <46800482.4020700@eagercon.com> <46801FDD.4020408@eagercon.com> <468047F0.7060207@eagercon.com> <46814B4C.7080302@eagercon.com> <46819C43.7040506@eagercon.com> From: Jim Blandy Date: Tue, 26 Jun 2007 23:39:00 -0000 In-Reply-To: <46819C43.7040506@eagercon.com> (Michael Eager's message of "Tue, 26 Jun 2007 16:07:47 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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: 2007-06/txt/msg00324.txt.bz2 Michael Eager writes: > Yes, contributing to public sources is a goal. Okay, that's great to hear. > There are always factors which complicate this. > - Working in different versions of GDB, with the need to port > modifications from one version to another. There have been > many changes in GDB which make code non-portable between > different versions. > - An interest in making minimal changes to solve a problem > rather than engage in a major redesign effort. > > I'm helping the folks who are developing the UPC support for GDB. > The sources are available on-line. I understand that they have an > interest in submitting patches to support UPC when the code is a > bit more stable. There's support in DWARF for UPC features, but > the UPC language extensions have not yet been incorporated into > the current version of GCC. Right. Well, speaking generally, then: - Some of what you're doing seems to resemble multi-process debugging. Ulrich and Markus have been working on stuff for the Cell processor which I think is similar, in that it involves a single GDB addressing a number of separate address spaces. So if that work turns out the way I think it will, GDB trunk will be a more hospitable place for work like this. - UPC shared arrays seem to have subscripting rules that differ from those of standard C. It's fine to go ahead and change things like value_subscript to handle these; those functions bear the responsibility of supporting multiple languages in the current design. - As I've said, I recommend using CORE_ADDR to represent global addresses only. The target may have other kinds of addresses; those should be promoted to CORE_ADDRs for use within GDB. I'd expect POINTER_TO_ADDRESS and ADDRESS_TO_POINTER to be the places this happens, but you may find that you want to add a new FRAME_POINTER_TO_ADDRESS method, so that you can use information from a value's execution context to construct the global address.