This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA][3/5] New port: Cell BE SPU (the port itself)
- From: "Mark Kettenis" <mark dot kettenis at xs4all dot nl>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: "Mark Kettenis" <mark dot kettenis at xs4all dot nl>, gdb-patches at sourceware dot org
- Date: Sun, 12 Nov 2006 22:41:34 +0100 (CET)
- Subject: Re: [RFA][3/5] New port: Cell BE SPU (the port itself)
- References: <200611121538.kACFcN1Q013275@d12av02.megacenter.de.ibm.com>
> 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