<br><font size=2><tt>John DelSignore <jdelsign@totalviewtech.com>
wrote on 07/13/2007 02:07:27 PM:<br>
<br>
> What use is it to be able to write to npc? It seems like the only
<br>
> circumstance under which writing npc it might have an effect is when<br>
> the SPU thread is running. That seems dubious, because I'm not sure
<br>
> if it makes sense to change the PC of a running SPU thread.<br>
</tt></font>
<br><font size=2><tt>No, that actually won't have any effect. I agree,
there is basically</tt></font>
<br><font size=2><tt>no use in allowing the modify the npc file; I guess
it should better</tt></font>
<br><font size=2><tt>be read-only.</tt></font>
<br>
<br><font size=2><tt>For consistency, I guess it would then also make sense
to provide</tt></font>
<br><font size=2><tt>the npc in the core file.</tt></font>
<br><font size=2><tt><br>
> How does the debugger change the PC of a stopped SPU thread? Is it
<br>
> necessary for the debugger to find the PPU thread associated with
<br>
> the SPU thread, and change the PC by writing to the location pointed<br>
> to by the PPU's R4 register? If that is true, then it seems that the<br>
> debugger can change the PC value of an SPU thread only if it has an
<br>
> associated thread.<br>
</tt></font>
<br><font size=2><tt>That is correct. While it makes sense to refer
to the PC where an SPU</tt></font>
<br><font size=2><tt>context last stopped (and this is what a read from
the npc file will give</tt></font>
<br><font size=2><tt>you), there is no sense in asking for the PC where
an SPU context will</tt></font>
<br><font size=2><tt>continue. This is because the the only interface
to contine an SPU</tt></font>
<br><font size=2><tt>context takes a PC parameter, and it will always continue
there.</tt></font>
<br>
<br><font size=2><tt>If you do not know which piece of (PPE) code will
call that interface,</tt></font>
<br><font size=2><tt>and what PC parameter it will pass, you fundamentally
cannot know</tt></font>
<br><font size=2><tt>where the context will continue.</tt></font>
<br><font size=2><tt> <br>
> How does the debugger find the PC of a stopped SPU thread if there
<br>
> is no associated PPU thread? I believe it is possible for a PPU <br>
> thread to run an SPU thread for a while, and then the SPU thread can<br>
> stop, at which point the PPU may go off and do something else <br>
> leaving the SPU context stopped and unassociated. The SPU context
<br>
> still exists and the debugger would like to be able to find the SPU
<br>
> thread's PC at the time it stopped. Is the SPU thread's PC at the
<br>
> time it stopped saved in the npc file? Or does the debugger need to
<br>
> dig out the SPU thread's PC at the time it stopped from somewhere
else?</tt></font>
<br>
<br><font size=2><tt>A read from npc will give you the PC where the context
last stopped.</tt></font>
<br>
<br><font size=2><tt>> However, in my opinion, SPU/PPU thread association
is orthogonal to <br>
> showing the user the complete state of an SPU context. A very <br>
> important part of the SPU state is its PC, and we'd like to be able
<br>
> to show users the PC value for SPU contexts whether or not they <br>
> currently have an associated PPU thread, and whether or not it's a
<br>
> live process or a core file. Unlike GDB, my goal for TotalView is
<br>
> show the user all of the PPU threads and SPU contexts at the same
<br>
> time, including SPU threads that do not currently have an associated<br>
> PPU thread.<br>
</tt></font>
<br><font size=2><tt>The next release of GDB will show SPE contexts that
are currently</tt></font>
<br><font size=2><tt>interrupted by a PPE-assisted call, using a new interface
provided</tt></font>
<br><font size=2><tt>by libspe2 to find them. GDB will not attempt
to display SPE context</tt></font>
<br><font size=2><tt>that are not within spe_context_run at all.</tt></font>
<br>
<br><font size=2><tt>To use that libspe2 interface, you'll have to use
a current version</tt></font>
<br><font size=2><tt>of libspe2 (from the sourceforge repository). It
will allocate a data</tt></font>
<br><font size=2><tt>structure </tt></font>
<br>
<br><font size=2><tt>struct spe_context_info {</tt></font>
<br><font size=2><tt> int spe_id;</tt></font>
<br><font size=2><tt> unsigned int npc;</tt></font>
<br><font size=2><tt> unsigned int status;</tt></font>
<br><font size=2><tt> struct spe_context_info
*prev;</tt></font>
<br><font size=2><tt>};</tt></font>
<br>
<br><font size=2><tt>on the stack of the spe_context_run function, identifying
the SPE id</tt></font>
<br><font size=2><tt>(spufs file handle) of the SPE context it is about
to run (or was just</tt></font>
<br><font size=2><tt>running), as well as the associated NPC and spe_run
return status.</tt></font>
<br>
<br><font size=2><tt>The library will also maintain a per-thread global
variable:</tt></font>
<br>
<br><font size=2><tt>thread struct spe_context_info *__spe_current_active_context;</tt></font>
<br>
<br><font size=2><tt>holding a linked list of such structures currently
active in the</tt></font>
<br><font size=2><tt>given thread (it is possible to do a nested spe_context_run
in</tt></font>
<br><font size=2><tt>a PPE-assisted call interrupting another spe_context_run).</tt></font>
<br>
<br><font size=2><tt>The debugger can then associate that linked list with
the PPE</tt></font>
<br><font size=2><tt>stack backtrace to find out which SPE context will
be resumed</tt></font>
<br><font size=2><tt>when returning to spe_context_run frames up on the
stack.</tt></font>
<br>
<br><font size=2><tt>GDB will use that information to show intermixed PPE/SPE</tt></font>
<br><font size=2><tt>stack backtraces.</tt></font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Mit freundlichen Gruessen / Best Regards<br>
<br>
Ulrich Weigand<br>
<br>
-- <br>
Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>
GNU compiler/toolchain for Linux on System z and Cell BE<br>
IBM Deutschland Entwicklung GmbH<br>
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung:
Herbert Kircher<br>
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294</font>
<br>