From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30670 invoked by alias); 25 Jun 2007 22:55:51 -0000 Received: (qmail 30661 invoked by uid 22791); 25 Jun 2007 22:55:50 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Jun 2007 22:55:48 +0000 Received: (qmail 24099 invoked from network); 25 Jun 2007 15:55:46 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 25 Jun 2007 15:55:46 -0700 Message-ID: <468047F0.7060207@eagercon.com> Date: Mon, 25 Jun 2007 22:55:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Jim Blandy 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00279.txt.bz2 Jim Blandy wrote: > Michael Eager writes: >> For an example, the SPEs in a Cell processors could be configured >> to distribute pieces of an array over different SPEs. >> >>> How do you declare such an array? How do you index it? What code is >>> generated for an array access? How does it relate to C's rules for >>> pointer arithmetic? >> In UPC (a parallel extension to C) there is a new attribute "shared" >> which says that data is (potentially) distributed across multiple processors. >> >> In UPC, pointer arithmetic works exactly the same as in C: you can >> compare pointers, subtract them to get a difference, and add integers. >> The compiler generates code which does the correct computation. > > All right. Certainly pointer arithmetic and array indexing need to be > fixed to handle such arrays. Support for such a system will entail > having the compiler describe to GDB how to index these things, and > having GDB understand those descriptions. This may be more something that is better described in an ABI than in DWARF. The compiler may not know how to translate a pointer into a physical address. UPC, for example, allows you to specify the number of threads at runtime. The compiler certainly can identify that an array or other data is shared, to use UPC's terminology. From there, the target code would need to perform some magic to figure out where the address actually pointed to. > If those were fixed, how do the other CORE_ADDR uses look to you? > Say, in the frame code? Or the symtab code? There are uses of CORE_ADDR values which assume that arithmetic operations are valid, such as testing whether a PC address is within a stepping range. These are not likely to cause problems, because code space generally does conform to the linear space assumptions that GDB makes. There are other places where an address is incremented, such as in displaying memory contents. I doubt that the code knows what what it is displaying, only to display n words starting at x address in z format. This would probably result in incorrect results if the data spanned from one processor/thread to another. (At least at a first approximation, this may well be an acceptable restriction.) Symtab code would need a hook which converted the ELF into a for shared objects. Again, that would require target-dependent magic. I think that there's some similarity with TLS handling, but I haven't looked at this closely. This sounds pretty straight forward. One problem may be that it may not be clear whether one has a pointer to a linear code space or to a distributed NUMA data space. It might be reasonable to model the linear code space as a 64-bit CORE_ADDR, with the top half zero, while a NUMA address has non-zero values in the top half. (I don't know if there might be alias problems, where zero might be valid for the top half of a NUMA address.) I'd be very happy figuring out where to put a hook which allowed me to translate a NUMA CORE_ADDR into a physical address, setting the thread appropriately. A bit of a kludge, but probably workable. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077