From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9663 invoked by alias); 12 Nov 2006 21:42:06 -0000 Received: (qmail 9642 invoked by uid 22791); 12 Nov 2006 21:42:05 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr4.xs4all.nl (HELO smtp-vbr4.xs4all.nl) (194.109.24.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Nov 2006 21:41:59 +0000 Received: from webmail.xs4all.nl (dovemail8.xs4all.nl [194.109.26.10]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id kACLfUof007121; Sun, 12 Nov 2006 22:41:34 +0100 (CET) (envelope-from mark.kettenis@xs4all.nl) Received: from 82.92.89.47 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Sun, 12 Nov 2006 22:41:34 +0100 (CET) Message-ID: <13750.82.92.89.47.1163367694.squirrel@webmail.xs4all.nl> In-Reply-To: <200611121538.kACFcN1Q013275@d12av02.megacenter.de.ibm.com> References: <200611121538.kACFcN1Q013275@d12av02.megacenter.de.ibm.com> Date: Sun, 12 Nov 2006 21:42:00 -0000 Subject: Re: [RFA][3/5] New port: Cell BE SPU (the port itself) From: "Mark Kettenis" To: "Ulrich Weigand" Cc: "Mark Kettenis" , gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/msg00091.txt.bz2 > Hi Mark, > > thanks for looking at the port! > > > First, "spu" doesn't occur anywhere in config.guess. Is this a name the > > community agrees on? I understand it stands for Synergistic Processor > > Unit, > > and it seems a bad idea to me that's a fairly generic term. > > "spu" cannot occur as host architecture, therefore it is not in > config.guess. > It is, however, in config.sub as a target architecture, and the recently > committed binutils patch uses it (as does the proposed GCC patch and all > the > previously released toolchain packages for Cell, both for Linux and the > PS3). Ok, > > > > * config/spu/spu-cell.mt: New file. > > > * config/spu/spu.mt: New file. > > > > Two .mt files? I think spu-cell.mt should be renamed spu.mh. > > Since spu is never the host architecture, spu.mh would not get used. > > The situation is a bit unique here: The spu debugger is itself a PowerPC > binary and runs on the PowerPC side of the Cell, but it debugs code > running > on the SPU side, so it would be a "cross" configuration. On the other > hand, > the debugger makes use of special host operating system facilities (ptrace > plus the spufs file system) to control the SPU inferior -- in this aspect > it looks like a "native" configuration. I think *is* a native configuration. > > I've tried different ways to integrate this scenario into the GDB > configure > structure, and what I've come up with appeared to me to be the most > straight- > forward way. I think it is fundamentally wrong to put native-dependent code in a .mt file. > 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? > > I also think SPU_NUM_CORE_REGS is a bad name. I first thought > > this had something to do with core files. > > Agreed, I've renamed it. > > > May I suggest SPU_NUM_VEC_REGS. > > Since the SPU ISA calls them "general-purpose registers" (and it's a bit > less to type), I'm now using SPU_NUM_GPRS. OK? Personally I'd prefer something that follows the SPU_NUM_XXX_REGS pattern, but that's not terribly important. Mark