[rfc] [0/9] Cell multi-arch debugger

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hello,

after the patches to eliminate current_gdbarch are now upstream, here's
a new patch set to introduces the Cell/B.E. multi-architecture debugger.

Some background on the Cell architecture and programming model.  From a
user-space software perspective, we have a regular PowerPC Linux system.
In addition, the kernel provides access to SPU processor hardware via a
set of system calls, spu_create and spu_run.  There is a SPE management
library ("libspe") that sits on top of those system calls and provides
an interface to user space applications that want to run SPU code.

spu_create allocates a "SPU context", which is a virtualized representation
of SPU hardware, including memory ("local store"), register set, and other
features.  The kernel schedules all SPU contexts allocated by processes in
the system onto the physical SPUs present at the hardware level.  Each SPU
context is identified via an SPU context ID, a small integer (actually a
file descriptor).  A special virtual file system ("spufs") holds a directory
for each SPU context in the system; files in that directory allow accessing
(and modifying) properties of that context, including memory and register
contents.

spu_run transfers control from PowerPC code to SPU code running in a 
particular SPU context.  The context ID and the PC to start execution
are passed as arguments to that system call.  If the system call is
interrupted (e.g. due to SPU code hitting a breakpoint), the current
PC is updated by the kernel, so that restarting the system call will
restart SPU execution at the point it was interrupted.  (This allows the
debugger to modify the PC before restarting as well.)

In addition to abstracting the spu_create and spu_run system calls, the
libspe library also provides an ELF loader that allows loading of ELF
executables in the SPU format into an SPU context.  To enable the debugger
to understand which executable is currently loaded where, each context
has an "object-id" property which is set by libspe to point to the in-memory
location of the ELF image that was loaded into this context.  (libspe
supports both loading of stand-alone executable files, which are memory-
mapped, and loading of SPU executable images that were embedded as data
sections into the main PowerPC executable or shared library.)  In addition,
each time a context is created or destroyed, or the object-id property of
any context is modified, the libspe library will call a special routine
__spe_context_update_event.  This allows the debugger to set a breakpoint
there to get informed of such events.

Some tasks (like I/O) are difficult for SPU code to perform.  Therefore,
libspe implements so-called "PPE-assisted calls", where the SPU application
stops using a particular termination code.  This is interpreted by the
libspe library as request to perform a particular action on behalf of the
SPU code.  After this is done, libspe will automatically restart SPU
execution.

Code running on a Cell system will typically be a PowerPC executable that
creates one or more SPU contexts, loads code from an SPU executable into
them, and runs them.  As the spu_run call is synchronous, the application
will often create a separate thread to run the spu_run call in.

As a special case, Cell systems are also set up to run a stand-alone SPU
executable directly.  This works via the Linux binfmt_misc handler: if
you start an SPU executable, the kernel will invoke a small loader via
binfmt_misc; and this loader will create a SPU context, load the binary
into it, and just run it.

The Cell multi-arch debugger is supposed to be able to debug both types
of applications.  For the case of SPU stand-alone applications, this is
in effect a replacement of the existing SPU native target.

Native, remote (via gdbserver) and core file debugging should all be 
supported.  Access to SPU properties happens at a low level via the
TARGET_OBJECT_SPU object type, which is implemented by spufs access 
in the native (and gdbserver) targets, by the qXfer packet type via
the remote protocol, and by special "SPU/" note sections in core files.

GDB will represent SPU executables as "shared libraries" to the main process.
The GDB internal address space (values of CORE_ADDR) is encoded to be able
to represent both PowerPC main memory and the memory of all active contexts:
Adresses with most significant bit zero are PowerPC addresses.  Addresses with
most significant bit one are SPU addresses, and encode the context ID in the
high 32-bit (except the MSB), and the local store address in the low 32-bit.
(We require a 64-bit CORE_ADDR for the Cell multi-arch debugger.)


At this point, most of the core infrastructure changes are already present
in mainline.  The patch set adds the following pieces:

- Target description support to identify a Cell/B.E. system and allow using
  an SPU executable with a target (inferior process) of PowerPC architecture.

- Support for the TARGET_OBJECT_SPU object type in the Linux native target,
  gdbserver, and core file target.

- Support to represent SPU executables as "shared libraries" and encode
  SPU content ID into CORE_ADDR addresses.

- Access register sets of multiple architectures for any given thread, and
  determine the "current" architecture of the thread.

- Per-frame architecture and unwinder support to allow a "stack backtrace"
  that shows where PowerPC code called SPU code via a spu_run system call,
  and where SPU code called PowerPC code via a "PPE-assisted call".

- Support for the "set spu stop-on-load" command and __ea pointer support.

- A set of test cases.


The whole patch set was tested with no regressions on the powerpc-linux,
powerpc64-linux, and spu-elf (the existing SPU native target).  It also
passed the whole spu-elf test suite executed in the powerpc-linux debugger
(i.e. invoking SPU standalone executable support of the Cell debugger).
Finally, the new Cell multi-arch test cases all pass as well.

The only non-mainline patches needed for this patch set to work are the
breakpoint-related patches I posted earlier today:
http://sourceware.org/ml/gdb-patches/2009-07/msg00539.html
http://sourceware.org/ml/gdb-patches/2009-07/msg00540.html

Once those are in, I'm planning to commit this patch set as well
(in a week or two ...).   Any comments are welcome!


Eli, I think I've addressed in the documentation changes all issues you
raised when I last posted the patch series.  I've also now added NEWS
entries where appropriate.  Are the docu/NEWS changes OK?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com