[Cbe-oss-dev] How is a debugger supposed to find the SPU's PC value in a CBE core file?

[Ulrich Weigand]

John DelSignore <jdelsign at totalviewtech.com> wrote on 07/13/2007 02:07:27 
PM:

> What use is it to be able to write to npc? It seems like the only 
> circumstance under which writing npc it might have an effect is when
> the SPU thread is running. That seems dubious, because I'm not sure 
> if it makes sense to change the PC of a running SPU thread.

No, that actually won't have any effect.  I agree, there is basically
no use in allowing the modify the npc file; I guess it should better
be read-only.

For consistency, I guess it would then also make sense to provide
the npc in the core file.

> How does the debugger change the PC of a stopped SPU thread? Is it 
> necessary for the debugger to find the PPU thread associated with 
> the SPU thread, and change the PC by writing to the location pointed
> to by the PPU's R4 register? If that is true, then it seems that the
> debugger can change the PC value of an SPU thread only if it has an 
> associated thread.

That is correct.  While it makes sense to refer to the PC where an SPU
context last stopped (and this is what a read from the npc file will give
you), there is no sense in asking for the PC where an SPU context will
continue.  This is because the the only interface to contine an SPU
context takes a PC parameter, and it will always continue there.

If you do not know which piece of (PPE) code will call that interface,
and what PC parameter it will pass, you fundamentally cannot know
where the context will continue.
 
> How does the debugger find the PC of a stopped SPU thread if there 
> is no associated PPU thread? I believe it is possible for a PPU 
> thread to run an SPU thread for a while, and then the SPU thread can
> stop, at which point the PPU may go off and do something else 
> leaving the SPU context stopped and unassociated. The SPU context 
> still exists and the debugger would like to be able to find the SPU 
> thread's PC at the time it stopped. Is the SPU thread's PC at the 
> time it stopped saved in the npc file? Or does the debugger need to 
> dig out the SPU thread's PC at the time it stopped from somewhere else?

A read from npc will give you the PC where the context last stopped.

> However, in my opinion, SPU/PPU thread association is orthogonal to 
> showing the user the complete state of an SPU context. A very 
> important part of the SPU state is its PC, and we'd like to be able 
> to show users the PC value for SPU contexts whether or not they 
> currently have an associated PPU thread, and whether or not it's a 
> live process or a core file. Unlike GDB, my goal for TotalView is 
> show the user all of the PPU threads and SPU contexts at the same 
> time, including SPU threads that do not currently have an associated
> PPU thread.

The next release of GDB will show SPE contexts that are currently
interrupted by a PPE-assisted call, using a new interface provided
by libspe2 to find them.   GDB will not attempt to display SPE context
that are not within spe_context_run at all.

To use that libspe2 interface, you'll have to use a current version
of libspe2 (from the sourceforge repository).  It will allocate a data
structure 

struct spe_context_info {
        int spe_id;
        unsigned int npc;
        unsigned int status;
        struct spe_context_info *prev;
};

on the stack of the spe_context_run function, identifying the SPE id
(spufs file handle) of the SPE context it is about to run (or was just
running), as well as the associated NPC and spe_run return status.

The library will also maintain a per-thread global variable:

thread struct spe_context_info *__spe_current_active_context;

holding a linked list of such structures currently active in the
given thread (it is possible to do a nested spe_context_run in
a PPE-assisted call interrupting another spe_context_run).

The debugger can then associate that linked list with the PPE
stack backtrace to find out which SPE context will be resumed
when returning to spe_context_run frames up on the stack.

GDB will use that information to show intermixed PPE/SPE
stack backtraces.



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

-- 
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  GNU compiler/toolchain for Linux on System z and Cell BE
  IBM Deutschland Entwicklung GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: 
Herbert Kircher
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht 
Stuttgart, HRB 243294
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20070713/b6aaf0ea/attachment.htm>