[WIP] TI msp430 CIO support

[Tom Tromey]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

Kevin> The debugger based driver uses a simple breakpoint driven
Kevin> implementation.  The debugger places a breakpoint on a known location
Kevin> which is always called when debugger-based I/O is to be performed. 
Kevin> When the breakpoint at that location is hit, the debugger reads the
Kevin> details of the system call and its parameters from a memory based
Kevin> buffer.  The debugger writes back the output of the system call to the
Kevin> same buffer.  (See my patch for the exact details.)

I was also curious why this wasn't done on the stub side and just have
the stub emit the output packets.

Kevin> One of my early implementations of this functionality used a normal
Kevin> (but hidden) GDB breakpoint with a command list whose last command
Kevin> was "continue".  This is similar to the way that dprintf is implemented.

Another way is to have a hidden breakpoint and override its check_status
breakpoint_ops method.  Then, have this method always set bs->stop = 0.

This won't work for dprintf, since dprintf wants various user-visible
breakpoint tweaks to also work; but I think it would work fine for your
case.

Tom