Re: [RFA][3/5] New port: Cell BE SPU (the port itself)

[Daniel Jacobowitz <drow at false dot org>]

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