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

[Benjamin Herrenschmidt]

On Fri, 2007-07-13 at 19:37 +0200, Arnd Bergmann wrote:
> 
> The point here is that the application does not _have_ to continue the
> program at the point where it left. There are different models how
> a context can be used by the application. One model is to have
> callbacks
> that get executed as part of the SPU program, with the callback
> returning
> to the SPU when its done. We use that for system calls for example.
> 
> Another model is one where the application starts on the PPE and does
> separate function calls into the SPU, always passing a different npc
> value in when it starts.

Regardless of how the application uses it, it does make sense to be able
to see in a debugger where the SPE last stopped and the backtrace at
that point. Remember, you are trying to -debug- your application
here :-) Maybe your bug is exactly that the SPE thread stops when it
should not and thus you want to dig.

> For the first case, the NPC makes sense, but then you also have a
> thread
> that has the spe_run function in libspe2 in its backtrace that the
> debugger can find. In the second case, the debugger can't really tell
> what's going on.

It's still useful to know in a debugger what/how/where and with which
backtrace the last function stopped.

> I guess if libspe2 is built with the appropriate debugging information
> (as it
> should), you can easily peek into its data structures, like you do
> with
> any other library.

That is a bit gross... I think he makes a very good point about the
kernel maintaining the information in "npc" and including that in the
core dump would make a lot of sense.

Ben.