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

["Mark Kettenis" <mark.kettenis@xs4all.nl>]

>  Daniel Jacobowitz wrote:
>
> > On Sun, Nov 12, 2006 at 10:41:34PM +0100, Mark Kettenis wrote:
> > > 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.
>
>  Yes, exactly.   It's not just a matter of checking the executable file
>  architecture; a single process can have threads executing SPU code at
>  the same as other threads executing PowerPC code.

That's not really what I'm talking about.  I'm talking about having a single
gdb binary that is able to execute both native powerpc code and spu code
(but not at the same time).  As far as I can tell, it should be possible
to do that by implementing to_can_run() in both ppc-linux-nat.c and
spu-linux-nat.c, such that only one returns true at any time.

>  I have a set of patches that does appear to work so far; it is based
>  primarily on switching current_gdbarch on thread switch.  However,
>  there's still some work to be done before this is in a shape suitable
>  for mainline inclusion.

Andrew Cagney has talked a fair bit about this sort of things in the past.
His idea was that each frame would have a gdbarch.  But a gdbarch per
thread probably makes more sense.

>  Therefore I'd hoped it would be possible to get the SPU-only port
>  accepted first, since this is in itself already quite useful.

> > 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.
>
>  I'll have a look at the remote-foo targets.  Is it just more or less just
>  a matter of renaming the file, or are there significant differences?

I don't agree with Daniel here.  The spu-linux-nat.c target vector is
only usable on a powerpc native debugger.

Mark