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

[John DelSignore]

Hi Ulrich,

Thank you for your reply. It however raises a few more questions that I have typed in-line below...

Ulrich Weigand wrote:
> 
> Hi John,
> 
>> When I look at the notes in a CBE core file, the npc file seems to
>> be missing. For example:
> 
> Yes; the set of spufs we files added to the core file is basically the
> set of files that are used by GDB.  GDB does not use the npc file,
> because it cannot be meaningfully used to install a changed PC
> value (because every spu_run system call will reset the PC to the
> new value it gets passed as argument).

I see, you are saying that it doesn't make sense for GDB to change the PC of an SPU context by writing to the npc file because for a PPU thread that is stopped by the debugger, the spu_run system call will eventually be restarted, or libspe/libspe2 will call spu_run again, and the SPU thread will resume execution at the PC value provided to spu_run. In other words, the PC value provided to spu_run takes precedence over values written to npc which the SPU thread is stopped. That makes perfect sense to me.

Questions:

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.

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.

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?

>> So, where does one find the value of an SPU's PC at the time of the
> core dump?
> 
> GDB does the same on a core file as it does when debugging a
> running process: it will check at the location of the PPC PC and
> see if the thread is blocked in an spu_run system call; if so, it
> will find a pointer to the SPU's PC in register 4 (and spufs ID in
> register 3).

OK, that seems reasonable for SPU threads that actually have an associated 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?

> (Note that even if you had an npc file note in the core, you'd still
> have to do something along those lines in order to associate any
> particular SPE context with the thread that is currently running it,
> if any.)

Yes, my current thinking for our debugger TotalView, is that at any point in time SPU contexts may or may not have an associated PPU thread. As you say above, the debugger can establish that association by looking at PPU threads stopped in spu_run, finding the spufs ID in R3, and then finding the SPU context with the matching spufs ID.

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.

Your thoughts on this matter will be greatly appreciated.

Cheers, John D.
-- 
John V. DelSignore, Jr.                 jdelsign at totalviewtech.com
Chief Architect
TotalView Technologies (formerly Etnus) WWW:   http://www.totalviewtech.com
24 Prime Parkway                        Phone: (508) 652-7730
Natick, MA 01760                        FAX:   (508) 652-7787