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

Mark Kettenis
2006-11-13T12:43:24Z

> 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