Tue Jun 5 22:33:44 EDT 2012

Doing this stuff in GDB

What is so helpful about this is to start from the idea of "everyting
on the target" and then start offloading things to the host.  The big
idea here is that the target can "call host code".  For GDB, this
would mean:

  - set a breakpoint in a generic gdb_call() method.  use a single
    method to only have to use a single breakpoint.

  - disambiguate this call by using a scratch buffer in RAM that takes
    the parameters of an RPC call.

  - when a breakpoint fires, have GDB transfer this RPC param buffer
    to a handler, possibly an external program.
  - allow this handler program to call back into the program, and/or
    change the program's state.

Now, to simplify things, can the GDB part be limited to transferring
raw data packets between the target and some host process?  What I
really want is just a bi-directional message pipe.  Anything else can
go on top of that.

So basically, gdb_call() would give a command buffer to GDB, and
receive a reply.  This method would be called whenver there is a
target request or event, and called periodically to receive incoming

An a-symmetric RPC mechanism can carry calls in the other direction,
by embedding it into two calls: poll(), reply().

The main feature is really that the protocol is synchronous, so both
sides are always in a well-defined state.

So, what about this simplified version:

   - breakpoint at gdb_call
   - read target RAM buffer, save to req.bin (pipe?)
   - read from reply.bin (pipe?) into target RAM buffer
   - continue

Once the pingpong channel is organized, all the rest is software

  gdb -> ext : dump binary value <pipe> <variable>
  ext -> gdb : source <pipe>

hmm doesn't look like it..  gdb doesn't want to block on sourcing from
a pipe.  this probably needs a shell command to keep it synchronous.

  dump binary value req.bin gdb_req
  shell do_rpc
  source reply.gdb