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

[Arnd Bergmann]

On Friday 13 July 2007, John DelSignore wrote:

> 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. 

GDB starts out with the thread, that is where it gets the context from,
which means that it does not actually need to find it.

> 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?       

When there is no thread that runs a context, that also means that the state
of that context is not meaningful. In particular, the NPC value does not
have any significance then. GDB only knows about threads, not execution
units anyway. 
 
> OK, that seems reasonable for SPU threads that actually have an associate
> PPU thread at the time the core file was created, but what about SPU
> contexts that do not have an associated PPU thread at the time the core file
> was created? If the PC of a stopped SPU context with no associated PPU
> thread is not stored in the npc file, then where can the debugger find that
> SPU's PC?     

The libspe data structures still have the NPC value of where the
context last stopped. Assuming that one thread executes a callback
that was initiated from an SPE, you should still be able to see
the backtrace through the spe_run function that would return to
the SPE, but that requires knowledge of libspe internals.

> 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.

There is no fundamental difference between an "SPU thread" and
 "PPU thread, there is only one kind of thread, and it can
run on either the PPU or the SPU.

From the point of view of a debugger, an SPU context that is
not running is similar to a 'ucontext_t' data structure on the PPE:
you can do calls like 'setcontext()' or 'switchcontext()' on it,
but it does not have any other significance as long as it sits
in memory.

	Arnd <><