From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4798 invoked by alias); 12 Nov 2006 22:12:03 -0000 Received: (qmail 4785 invoked by uid 22791); 12 Nov 2006 22:12:02 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 12 Nov 2006 22:11:56 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GjNYI-0006aE-43; Sun, 12 Nov 2006 17:11:46 -0500 Date: Sun, 12 Nov 2006 22:12:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [RFA][3/5] New port: Cell BE SPU (the port itself) Message-ID: <20061112221146.GA24918@nevyn.them.org> Mail-Followup-To: Mark Kettenis , Ulrich Weigand , gdb-patches@sourceware.org References: <200611121538.kACFcN1Q013275@d12av02.megacenter.de.ibm.com> <13750.82.92.89.47.1163367694.squirrel@webmail.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13750.82.92.89.47.1163367694.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00093.txt.bz2 On Sun, Nov 12, 2006 at 10:41:34PM +0100, Mark Kettenis wrote: > > > This means I leave GDB's notion of "host" as auto-detected (i.e. > > powerpc64), > > which means that GDB does not configure as a "native" target (since target > > != host). However, the target-dependent files for the spu target actually > > include the spu-linux-nat.c file which installs itself onto the target > > stack > > and provides the "native" debugging capabilities that way. > > I think that what you really want is a Linux powerpc native configuration > that can debug both normal powerpc code and spu code. That'd mean adding > spu-linux-nat.c to config/powerpc/linux.mh. But I suppose that doesn't > really work right now. But could we make that work? In theory yes - but I'm not quite sure how. You'd have more than one target that could take control when you said "run" and for Cell I think you'd have to disambiguate based on the architecture of the file. But Ulrich said they had more patches that weren't ready for mainline and I bet some of them make this nicer :-) Since really you would want to debug both at once. In the mean time, I suppose you could configure a native powerpc64 debugger with some special flag that caused it to only work for SPU instead of PPC64, but if I had to come up with a way to do this, I'm afraid I'd end up with exactly what Ulrich did: a ppc-linux->spu-elf debugger that knew how to run things on the SPU. I guess what really is throwing us here is the use of "nat". Isn't this really more like one of the custom remote-foo.c targets than a native target? It just happens to be implemented using PowerPC/Linux kernel facilities spelled "ptrace" and some poking around in a PowerPC executable in order to implement "run". The ptrace facilities don't seem to be used much to talk to the SPU; new files in /proc are used instead. It's forking and running a PowerPC executable until it makes a special SPU-related syscall, and then it starts talking to the SPU. That's an oversimplification; this is quite twisty! -- Daniel Jacobowitz CodeSourcery