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

[John DelSignore]

Hi Ben,

Thank you for your comments...

While that would work, one of the difficulties with that approach is that there is no "spu_run syscall instruction" or dedicated stub. Instead, last I looked, spe_run()/spu_run() is implemented in terms of the syscall() function, which as you probably know is a generic system call stub. spu_run() in libspe2 is defined as:

static inline int spu_run(int fd, unsigned int *npc, unsigned int *status)
{
        return syscall(__NR_spu_run, fd, npc, status);
}

That would require the debugger to know that spu_run() is implemented in this manner and if the implementation changes the debugger stops working. And, since syscall() is a common function, the debugger would need to intercept all uses of syscall() and check the first argument, which would slow down the program depending on how many other uses of syscall() exist for other system calls. spe_run() in libspe has a similar structure.

That said, I'm not sure how the debugger would use a mechanism for a debugger to set a "break on entry" flag on a context. We are still very early in the porting phase for the Cell, so being able to reliably detect entry to and exit from spu_run() system calls might be extremely useful. One way I have seen this done in other libraries, like libpthreads, is to have dedicated "event" functions on which the debugger can set breakpoints, and the library calls the functions to report events to the debugger. For example, I can imagine something like this:

static inline int spu_run(int fd, unsigned int *npc, unsigned int *status)
{
	notify_gdb_spu_run_entry();
        int result = syscall(__NR_spu_run, fd, npc, status);
	notify_gdb_spu_run_exit();
	return result;
}

notify_gdb_spu_run_entry() and notify_gdb_spu_run_exit() would consist of nothing more than a "return" instruction, but that would allow the debugger set a breakpoint on one, both, or none of those functions, depending on the set of events that are of interest to the debugger. Of course, the above won't work with restarted system calls (the kernel backs up the PC to reexecute the sc instructions). Also, I'm sure there are other more efficient schemes, but you get general the idea: it's helpful to give the debugger a dedicated, easy to find place to set a breakpoint to report events.

One issue that arose, for which tracing entry/exit to/from spu_run() might be useful, is how to implement an SPU-context debugger "hold" and "unhold" mechanism. Debuggers that are capable of providing general asynchronous thread control would normally like to have a mechanism that allows the debugger to "hold" and "unhold" execution of a thread context. For the Cell, that would mean that if the debugger "held" an SPU context, the SPU context won't execute even if a PPU thread calls spu_run() for that context. If an SPU context is held, and a PPU thread calls spu_run() for that context, then the SPU's execution is blocked until the context is "unheld". With this simple hold/unhold mechanism, a debugger can provide user powerful thread-level execution control.

Do you know if there is such a hold/unhold mechanism for SPU contexts?

Cheers, John D.


Benjamin Herrenschmidt wrote:
>>> Would it be useful to provide a mechanism for a debugger to set a "break
>>> on entry" flag on a context, causing either libspe or the kernel to
>>> trigger a breakpoint stop on the next attempt at running anything in
>>> that context, regardless of the PC value ?
>> I'd guess that the debugger can implement that without libspe2
>> or kernel support, simply by setting a breakpoint on the
>> spu_run syscall instruction in libspe2 and ignoring the
>> breakpoint if its run on a context that you are not tracing.
> 
> Yup, that would work.
> 
> Ben.
> 
> 
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev
> 
>